11–20 of 80 posts
I have been in this business long enough to remember Clipper and FoxPro devs bitching about SQL when it was on the rise. This sounds about the same to me.
As is to be expected from this author, this is definitely on the flame-bait side of things. I submit it because I believe there is an important point here: for the vast majority of startups, going with a relatively unproven "NoSQL" database is a premature optimization and an unneeded technical risk. I disagree with the author that these databases are a flash in the pan, but their over-application is.
I dunno, I see the opposite: RDBMS's are a premature optimization. In my experience, it's /much/ easier to hack together a quick webapp in MongoDB, because you don't have to worry about relations, migrating schema, etc. Sure, it might be slower than Postgres on a billion-row table, but wait until you have a million rows before you shackle yourself to the relational constraints.
He has it backwards. You use NoSQL to 'get shit done'. When you have a billion rows, then worry about schemas. By that point you will have a much better idea, a - what said schema should look like, b - what the architecture of the Postgres, or mysql, or Oracle should look like, and c - how much money you will have to solve the problem.
NoSQL will never die, but it will eventually get marginalized, like how Rails was marginalized by NoSQL. Is it just me, or does this statement make absolutely no sense whatsoever?
NoSQL will never die, but it will eventually get marginalized, like how Rails was marginalized by NoSQL. Is it just me, or does this statement make absolutely no sense whatsoever?
NoSQL, as it exists today, is a tasty souffle composed of more air than substance. That's how the hype cycle works:
http://en.wikipedia.org/wiki/Hype_cycle
NoSQL is somewhere on that initial "peak of inflated expectations". (I don't think it's hit the top yet, but it sure is soaring.) Rails passed the peak many months ago and is somewhere to the right of the Trough of Disillusionment. [1] (I don't think it's plateaued yet: Rails still isn't quite done being invented.)
Once the hot air leaks out in a year or two, NoSQL databases will still exist, and will in fact be better understood and better built than ever, but they will no longer be a trending buzzword. That's the day that the author is devoutly wishing for.
(I, personally, find the hype cycle to be kind of fun to watch, and educational too, so I'm not as bothered by it as he is.)
---
[1] Though your mileage may vary. The world isn't perfectly connected, so there isn't just one hype cycle. It's fun watching (e.g.) Facebook sweep through the world of my parents. They get really excited by "new" technologies about two to four years after the folks on HN have moved on from them.
Earlier quoted context omitted.
I dunno, I see the opposite: RDBMS's are a premature optimization. In my experience, it's /much/ easier to hack together a quick webapp in MongoDB, because you don't have to worry about relations, migrating schema, etc. Sure, it might be slower than Postgres on a billion-row table, but wait until you have a million rows before you shackle yourself to the relational constraints.
Absolutely right. He has it backwards. You use NoSQL to 'get shit done'. When you have a billion rows, then worry about schemas. By that point you will have a much better idea, a - what said schema should look like, b - what the architecture of the Postgres, or mysql, or Oracle should look like, and c - how much money you will have to solve the problem.
NoSQL will never die, but it will eventually get marginalized, like how Rails was marginalized by NoSQL. Is it just me, or does this statement make absolutely no sense whatsoever?
Or maybe he's just saying that irrational NoSQL hype has replaced irrational Rails hype.
Ted's point may be valid for BigTable-like databases. (I'm not saying it is, but I don't know enough about those to say so.) Those are designed for scalability and if you don't need the scalability you probably should use a RDBMS instead. But there are other advantages of SQL-less databases that don't deal with scale. I deployed my first MongoDB app a couple weeks ago. Even though it was a small (~1 developer month)…
I got downvoted awfully last night for trying to say this, but I'll say it again to back you up: Developing with mongodb is _lightning fast_ and holds up very very well. If you end up with problems, switch to SQL later! I don't think a lot of these people hating on the nosql projects have actually tried building something with them.
Most of this is probably having expertise with the tools, but I find that for rapid prototyping the ability to run relational queries is really important, especially since query performance during the prototyping phase isn't really an issue.
NoSQL will never die, but it will eventually get marginalized, like how Rails was marginalized by NoSQL. Is it just me, or does this statement make absolutely no sense whatsoever?
NoSQL's hype will never die, but it will eventually get marginalized, like how Rails' hype was marginalized by NoSQL's hype.
NoSQL will never die, but it will eventually get marginalized, like how Rails was marginalized by NoSQL. Is it just me, or does this statement make absolutely no sense whatsoever?
If Rails == ActiveRecord == SQL, then NoSQL implies !Rails. (This isn't true of course, but we're already dealing with oversimplifications here.) Or maybe he's just saying that irrational NoSQL hype has replaced irrational Rails hype.
Earlier quoted context omitted.
I dunno, I see the opposite: RDBMS's are a premature optimization. In my experience, it's /much/ easier to hack together a quick webapp in MongoDB, because you don't have to worry about relations, migrating schema, etc. Sure, it might be slower than Postgres on a billion-row table, but wait until you have a million rows before you shackle yourself to the relational constraints.
Absolutely right. He has it backwards. You use NoSQL to 'get shit done'. When you have a billion rows, then worry about schemas. By that point you will have a much better idea, a - what said schema should look like, b - what the architecture of the Postgres, or mysql, or Oracle should look like, and c - how much money you will have to solve the problem.
Schemaless data should only be a summary of data properly maintained elsewhere, which you can regenerate at need. If your authoritative data has no schema, it will decay to garbage.