5 ms·
Generally speaking, I'd argue that data should almost always have a strict schema. But often times you don't have this kind of luxury: APIs are inconsistent and
by dvt 5y ago
Generally speaking, I'd argue that data should almost always have a strict schema. But often times you don't have this kind of luxury: APIs are inconsistent and you may not have the CPU cycles to spare for a transform step; you're quickly iterating on a proof of concept and aren't even sure what your final schema is going to look like; and so on.
From a practical perspective, SQL is much more idiomatic than mongoDB's confusing query "language." But, cards on the table, almost every single new project I start up, I start with MongoDB :)
- rocqua 5y agoEven if you want a strict schema, schema migration and updates are still nicer outside of sql.
- chousuke 5y agoI often hear mentions of "no schema" when people talk about NoSQL, but I think that's a lie; it's not possible for data to have no schema because an application that assumes its data has no structure can't do anything with that data. However, a schema can be dynamic. Having a dynamic schema implies that you get no guarantees from the database, so the application has to discover and validate the schema at runtime to be able to do useful things. I like data integrity so I prefer static schemas, but sometimes it can be useful to have a component in your tables where you do the extra work of dynamic inspection or just transport it as an opaque blob.