5 ms·

I've seen this cycle play out in realtime. I'm thankful for the flexibility that NoSQL added to the conversation, though. But I'm confident in sticking with S

I've seen this cycle play out in realtime. I'm thankful for the flexibility that NoSQL added to the conversation, though. But I'm confident in sticking with SQL for primary purposes, and only adding in NoSQL solutions when it really fits the requirements perfectly (and I can't see those requirements radically changing anytime soon).

collyw 10y ago
I looked at NoSQL when it was all the hype 5 years back and realized this sort of thing was going to be the case without ever needing to try it. NoSQL has its place, but the majority of apps don't seem to need it.
mikestew 10y ago
I do wonder if the inappropriate use of NoSQL is due to an ignorance of why we used SQL in the first place (and the article doesn't directly say this, but in a roundabout way does). In which case, perhaps the brief flirting with NoSQL at many companies served as a good reminder of "oh, yeah, queries and transactions are kind of important; I forgot about that because I began to take SQL for granted." IOW, you didn't know what you had until you went and used something else. And maybe you won't be so quick to jump on the next hyped bandwagon.
- WorldMaker 10y ago
  I think it has more to do with the fact that it's a giant spectrum and we've never quite managed to build something in a particular strong enough sweet spot so at least for now you are going to continue to see the pendulum swing between NoSQL and SQL (or more usefullly, Document and Relational) databases. What's worse is that there may probably be no mainstream acceptable sweet spot, every developer/team has their own particular preference, and we might never see the pendulum stop. The spectrum seems to be ad hoc data on the one hand versus ad hoc queries on the other. Document databases prioritize being able to store just about any ad hoc document you might need at the expense of being able to quickly pull off new ad hoc queries that you didn't originally plan for. Relational databases prioritize being able to query very complex relationships in just about any way you can imagine at the expense of making it hard to add new shapes of data. There's no right answer, just the answer that works best for you at the moment. The pendulum will probably keep swinging for a while, and we'll see more hybrids like we've been seeing Postgres and SQL Server embracing JSON more heavily, because the right answer is probably closer to the middle ground or at least "Why not both?".
  - 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 ago
      That's an oversimplification. I think WorldMaker hit it on the head: do you plan your queries up front, or your data?
    - WorldMaker 10y ago
      It'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.

collyw 10y ago

I looked at NoSQL when it was all the hype 5 years back and realized this sort of thing was going to be the case without ever needing to try it. NoSQL has its place, but the majority of apps don't seem to need it.

mikestew 10y ago

I do wonder if the inappropriate use of NoSQL is due to an ignorance of why we used SQL in the first place (and the article doesn't directly say this, but in a roundabout way does). In which case, perhaps the brief flirting with NoSQL at many companies served as a good reminder of "oh, yeah, queries and transactions are kind of important; I forgot about that because I began to take SQL for granted." IOW, you didn't know what you had until you went and used something else. And maybe you won't be so quick to jump on the next hyped bandwagon.

WorldMaker 10y ago
I think it has more to do with the fact that it's a giant spectrum and we've never quite managed to build something in a particular strong enough sweet spot so at least for now you are going to continue to see the pendulum swing between NoSQL and SQL (or more usefullly, Document and Relational) databases. What's worse is that there may probably be no mainstream acceptable sweet spot, every developer/team has their own particular preference, and we might never see the pendulum stop. The spectrum seems to be ad hoc data on the one hand versus ad hoc queries on the other. Document databases prioritize being able to store just about any ad hoc document you might need at the expense of being able to quickly pull off new ad hoc queries that you didn't originally plan for. Relational databases prioritize being able to query very complex relationships in just about any way you can imagine at the expense of making it hard to add new shapes of data. There's no right answer, just the answer that works best for you at the moment. The pendulum will probably keep swinging for a while, and we'll see more hybrids like we've been seeing Postgres and SQL Server embracing JSON more heavily, because the right answer is probably closer to the middle ground or at least "Why not both?".
- 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 ago
    That's an oversimplification. I think WorldMaker hit it on the head: do you plan your queries up front, or your data?
  - WorldMaker 10y ago
    It'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.