3 ms·
That’s the theory, in practice “no schema” in my recent painful experience translates to “move the schema into the apps” which really sucks when you have a bun
by gbuk2013 5y ago
That’s the theory, in practice “no schema” in my recent painful experience translates to “move the schema into the apps” which really sucks when you have a bunch of interdependent services owned by different teams.
And you still need to do joins to enrich data from different collections.
I want Postgres back. :(
- flowerlad 5y ago> really sucks when you have a bunch of interdependent services owned by different teams. That's true. The strictness of SQL lets you use SQL as the integration point. Without it you'd have to write a service on top as the integration layer.
- laichzeit0 5y agoIt’s exactly that. Shifting the problem from schema-on-write to schema-on-read. It’s like dynamic vs statically typed. Personally, I don’t like it at all, none of your problems have magically disappeared, you just shifted it to runtime (or the application layer, as you say).
- vel0city 5y agoIn many document databases these days you can have required fields and types enforced by the database to ensure all documents in the collection have at least a certain schema. https://docs.mongodb.com/manual/core/schema-validation/#restrictions https://docs.mongodb.com/manual/core/schema-validation/#rest...
- jjav 5y ago> “move the schema into the apps” Exactly. There is always a schema, there has to be. It's just a question of whether it can easily be seen or if it is buried in a thousand places in the code.