3 ms·
It's a question of up-front or down-the-line. Do you design your database schema, think out your queries and plan up-front? Or do you do ad-hoc, quick-turn-ar
by michaelchisari 10y ago
It's a question of up-front or down-the-line. Do you design your database schema, think out your queries and plan up-front? Or do you do ad-hoc, quick-turn-around development and deal with the technical debt down-the-line?
From the beginning, I saw NoSQL as being great for prototyping or MVP. But the reality of our industry is that you very rarely get to bang something out overnight, then rewrite it the "right way". Your prototype or MVP more often than not becomes the foundation of your stable, mature releases.
- paulddraper 10y agoThat's an oversimplification. I think WorldMaker hit it on the head: do you plan your queries up front, or your data?
- WorldMaker 10y agoIt's not really a question of up-front or down-the-line, even. Some projects may never need ad hoc queries because by the time they hit scale enough that they need such reporting they might go directly to BI tools (Cubes, Elastic Search, et al) or "Big Data" tools (Hadoop, Big Query, et al) without needing an intermediate SQL step. The same is true with transactions and consistency models. Some projects may never have a need for anything stronger than eventual consistency and may never need more complicated transactions beyond the scope of an individual JSON document. Even then, there are chunky hybrid solutions with good options for choosing a different ACID plan or locking mechanics or transaction capabilities, and just because most "NoSQL" databases are in the corner of eventually consistent and transactions only at the individual document level does not mean that all are (there are definitely exceptions out there). Again, there will always be projects and business domains on both sides of this "data spectrum". There's no wrong answer, just what's right for your specific project or business domain.