4 ms·

When you say object "instances" of "types" then what you're referring to is a strong schema. That works in relational databases but RavenDB is a document/schema

When you say object "instances" of "types" then what you're referring to is a strong schema. That works in relational databases but RavenDB is a document/schemaless database so there will always be some overhead. RavenDB has collection-level compression across multiple documents which minimizes this: https://ravendb.net/articles/ravendb-5-0-features-smart-document-compression https://ravendb.net/articles/ravendb-5-0-features-smart-docu...

SigmundA 4y ago
>When you say object "instances" of "types" then what you're referring to is a strong schema. Yes that's exactly what I said. .Net is a strongly typed language with a strongly typed data model, hence my point of RavenDB not being a .Net data model even though it's written in .Net. I want a .Net DB that takes advantage of the type system rather than a JSON DB I can access with a .Net client, there are plenty of those. Document compression with dictionary training in a schemaless databases is a bandaid over their fact there is no schema. A Relational DB saves a ton of space with increased performance and lower CPU (rather than decreased performance and higher CPU with compression) because it has a strongly typed schema and therefore does not need to read/write the column names and types for every row and it can serialize column data to their most efficient form based on the type. This sort of efficiency flows through the entire system including better cache utilization, smaller indexes, and less data sent over the wire to the client. You can still do compression on top of a schema for even more savings like most DB's but you can do even more interesting storage techniques like column storage vs row storage if you have a schema that can really save space and increase performance depending on usage. A .Net DB could similar things again because if a strong type system. RavenDB looks like it has come a long way and Ayende definitely knows databases and .Net, however I am not a big fan of the JSON/document database philosophy, just my option based on experience. I prefer a strongly typed system that has an untyped escape hatch when needed, like PG with JSONB columns. That way you can stick to strong types and loose documents sparingly when needed. In a .Net DB that would be dynamic types being transparently stored with a loss of efficiency.
- manigandham 4y ago
  I'm not really sure what you're talking about then. What exactly is a .NET database? Every language has its own implementation of in-memory classes and instances, and these are translated over some protocol to a database that then translates to a on-disk format for persistence. That's how they all work, with various trade-offs. If you want a ".NET database", the only example would be to simply dump the in-memory bytes to disk, which you can through the various serializers in the framework.

SigmundA 4y ago

>When you say object "instances" of "types" then what you're referring to is a strong schema. Yes that's exactly what I said. .Net is a strongly typed language with a strongly typed data model, hence my point of RavenDB not being a .Net data model even though it's written in .Net. I want a .Net DB that takes advantage of the type system rather than a JSON DB I can access with a .Net client, there are plenty of those. Document compression with dictionary training in a schemaless databases is a bandaid over their fact there is no schema. A Relational DB saves a ton of space with increased performance and lower CPU (rather than decreased performance and higher CPU with compression) because it has a strongly typed schema and therefore does not need to read/write the column names and types for every row and it can serialize column data to their most efficient form based on the type. This sort of efficiency flows through the entire system including better cache utilization, smaller indexes, and less data sent over the wire to the client. You can still do compression on top of a schema for even more savings like most DB's but you can do even more interesting storage techniques like column storage vs row storage if you have a schema that can really save space and increase performance depending on usage. A .Net DB could similar things again because if a strong type system. RavenDB looks like it has come a long way and Ayende definitely knows databases and .Net, however I am not a big fan of the JSON/document database philosophy, just my option based on experience. I prefer a strongly typed system that has an untyped escape hatch when needed, like PG with JSONB columns. That way you can stick to strong types and loose documents sparingly when needed. In a .Net DB that would be dynamic types being transparently stored with a loss of efficiency.

manigandham 4y ago
I'm not really sure what you're talking about then. What exactly is a .NET database? Every language has its own implementation of in-memory classes and instances, and these are translated over some protocol to a database that then translates to a on-disk format for persistence. That's how they all work, with various trade-offs. If you want a ".NET database", the only example would be to simply dump the in-memory bytes to disk, which you can through the various serializers in the framework.