5 ms·
> 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 "techn
by 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 agoAll 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.