3 ms·

I guess this might explain some of its popularity but I think it has much more to do with the fact you don't have to do any advance planning about your data (i.

I guess this might explain some of its popularity but I think it has much more to do with the fact you don't have to do any advance planning about your data (i.e. no need to write schemata). "Rapid prototyping" is much easier when you don't have to think about the your data, its types nor the relationships between them. Of course, moving out of this phase becomes a massive headache, since basing your product on essentially unstructured data is a very good definition of "technical debt". And if you're using structured data in your rapidly prototyped object, why not just a RDBMS in the first place? :)

vertex-four 12y ago
> Of course, moving out of this phase becomes a massive headache, since basing your product on essentially unstructured data is a very good definition of "technical debt". Of course, it's possible to use things like JSON-Schema to validate your data if you choose to. > And if you're using structured data in your rapidly prototyped object, why not just a RDBMS in the first place? Because where's the RDBMS with a "natural" query language that is well-suited to complex, dynamic queries and document structures? How do people model a document store, with the ability to point to differently-shaped data, in an RDBMS without giving up all that safety?
- mattdeboard 12y ago
  All what safety? Anyway, I've used and have used both kinds of data stores. They have their places. Solr's a great document store with a very good distributed data story, for example. Not to mention interesting nested documents & queries features. For the most part though, you'd have a hard time convincing me that MongoDB or COuchDB (or whatever other document stores) are good enough as the system of record for actual products. Yes, relational databases require a lot more thought about your data. That's the point.

vertex-four 12y ago

> Of course, moving out of this phase becomes a massive headache, since basing your product on essentially unstructured data is a very good definition of "technical debt". Of course, it's possible to use things like JSON-Schema to validate your data if you choose to. > And if you're using structured data in your rapidly prototyped object, why not just a RDBMS in the first place? Because where's the RDBMS with a "natural" query language that is well-suited to complex, dynamic queries and document structures? How do people model a document store, with the ability to point to differently-shaped data, in an RDBMS without giving up all that safety?

mattdeboard 12y ago
All what safety? Anyway, I've used and have used both kinds of data stores. They have their places. Solr's a great document store with a very good distributed data story, for example. Not to mention interesting nested documents & queries features. For the most part though, you'd have a hard time convincing me that MongoDB or COuchDB (or whatever other document stores) are good enough as the system of record for actual products. Yes, relational databases require a lot more thought about your data. That's the point.