4 ms·
While I understand the initial appeal of schemaless databases in my experience the schema is the best living documentation of the shape of the data. It becomes
by haney 12y ago
While I understand the initial appeal of schemaless databases in my experience the schema is the best living documentation of the shape of the data. It becomes really handy to decouple this from the application layer when you start having multiple clients connecting to the database (transactional vs analytics workloads). I've also had my fair share of seemingly non deterministic behavior when working well tested code hits old data that you forgot was in a slightly different format.
- donw 12y agoExactly. Your database may be schemaless, but your data sure isn't.
- jn 12y ago> when you start having multiple clients connecting to the database If you assume that will happen, then all the things you suggest are true: the schema is indeed the best documentation, and clients will have to pay close attention to versioning since you can really only have one version of a fixed schema at a time. You'll probably also want to move business logic into the database in the form of foreign key constraints, triggers and the like. Getting that right is really important to protect against a broken client corrupting data. But that isn't the only strategy. You can instead have clients connect to an API, with the API implementation being the only thing that connects to the database. The API becomes the documentation. It can handle versioning. It handles business logic. In this world, the database schema is much less important, and you can safely use schemaless databases. Both designs have their advantages, and multiple clients connecting directly to the database may well be a better choice in many circumstances, but it's not inevitable.