3 ms·

But the database doesn't need to be the component enforcing those schemas, right? They could validate the schema of a document on storage and retrieval. And kee

by jusssi 6y ago

But the database doesn't need to be the component enforcing those schemas, right? They could validate the schema of a document on storage and retrieval. And keeping the schema version within a document would allow for multiple schema versions to exist within a single collection, which then would allow lazy migrations. I'm not saying I'd choose Mongo specifically for this job (if for anything), but the lack of DB enforced schema might not be the biggest problem here.

arcturus17 6y ago
This is the problem I’m alluding to in another comment about NoSQL in this thread. Why would you want to enforce the schema in code when the DB could do it for you? It becomes such a mess and such a burden for the developer!
- sjwright 6y ago
  That’s not always true. Often it’s not true. There’s a reason why we don’t have file systems that guarantee all .jpg files are valid JPEG files.
  - WJW 6y ago
    Now I want a filesystem that guarantees all .jpg files are valid JPEGs.
    - sjwright 6y ago
      Until you need to do an emergency transfer of some recovered data volume and there’s a few dozen slightly corrupted JPEGs scattered throughout a few million files. Also, I don’t think I’d want my filesystem deciding what qualifies as a valid JPEG. But yes, I can see the theoretical appeal.
AndrewDucker 6y ago
That means either only one place accesses the database (and becomes a bottleneck for change) or everywhere that accesses it has to keep their schemas in line. Neither of those sound like great situations to be in.
- sjwright 6y ago
  I’m a big proponent of schema-rich SQL but I don’t see the argument here. Enforced schemas can be a bottleneck for change no matter where it’s enforced. And just because some parts of a schema need to be “in line” doesn’t mean all of it must be. Maybe I care that “Customer ID” is enforced, but not “Australian Tax File Number” or “Document revision annotations”.

by jusssi 6y ago

arcturus17 6y ago

This is the problem I’m alluding to in another comment about NoSQL in this thread. Why would you want to enforce the schema in code when the DB could do it for you? It becomes such a mess and such a burden for the developer!

sjwright 6y ago
That’s not always true. Often it’s not true. There’s a reason why we don’t have file systems that guarantee all .jpg files are valid JPEG files.
- WJW 6y ago
  Now I want a filesystem that guarantees all .jpg files are valid JPEGs.
  - sjwright 6y ago
    Until you need to do an emergency transfer of some recovered data volume and there’s a few dozen slightly corrupted JPEGs scattered throughout a few million files. Also, I don’t think I’d want my filesystem deciding what qualifies as a valid JPEG. But yes, I can see the theoretical appeal.

AndrewDucker 6y ago

That means either only one place accesses the database (and becomes a bottleneck for change) or everywhere that accesses it has to keep their schemas in line. Neither of those sound like great situations to be in.

sjwright 6y ago
I’m a big proponent of schema-rich SQL but I don’t see the argument here. Enforced schemas can be a bottleneck for change no matter where it’s enforced. And just because some parts of a schema need to be “in line” doesn’t mean all of it must be. Maybe I care that “Customer ID” is enforced, but not “Australian Tax File Number” or “Document revision annotations”.