The problem isn't that NoSQL is bad - it's not. The problem is that the scale of data needed for its benefits to outweigh its shortcomings is, well, staggering. For anything less, a well configured RDBMS will be right there performance-wise and will give you the added safety measures that only decades of real-world experience can provide.
I can understand wanting to try something different. NoSQL is very interesting in that regard. If you're talking about using it in a personal or non-critical work project, then by all means, go right ahead. But if you want to build a critical project and take it to production, old school is the way to go.
I'm with the guys claiming premature optimization.
I think you've been duped by the legion of NoSQL evangelists into thinking RDBMS are old, slow and obsolete and if you put a few thousand rows into a few tables they'll bog down and take minutes to query it. Here's a spoiler: they're wrong. I think you'd be amazed just how robust and fast Postgres, MySQL and MS SQL can be if configured and used correctly.
The question NoSQL actually answers is "would you sacrifice atomicity and some consistency for a much higher data throughput?" I work on projects that have to manage sizable chunks of data every day and in my experience NoSQL is only an option after you've exhausted all other avenues. If you've designed a bulletproof database schema, optimized all your queries to the bone, created every possible index on every possible table, partitioned your database files and even thrown hardware at it and you still have issues, then NoSQL might be your salvation. Otherwise, stick to what everybody else is using.
Slashdot Mirror
The problem isn't that NoSQL is bad - it's not. The problem is that the scale of data needed for its benefits to outweigh its shortcomings is, well, staggering. For anything less, a well configured RDBMS will be right there performance-wise and will give you the added safety measures that only decades of real-world experience can provide. I can understand wanting to try something different. NoSQL is very interesting in that regard. If you're talking about using it in a personal or non-critical work project, then by all means, go right ahead. But if you want to build a critical project and take it to production, old school is the way to go.
I'm with the guys claiming premature optimization. I think you've been duped by the legion of NoSQL evangelists into thinking RDBMS are old, slow and obsolete and if you put a few thousand rows into a few tables they'll bog down and take minutes to query it. Here's a spoiler: they're wrong. I think you'd be amazed just how robust and fast Postgres, MySQL and MS SQL can be if configured and used correctly. The question NoSQL actually answers is "would you sacrifice atomicity and some consistency for a much higher data throughput?" I work on projects that have to manage sizable chunks of data every day and in my experience NoSQL is only an option after you've exhausted all other avenues. If you've designed a bulletproof database schema, optimized all your queries to the bone, created every possible index on every possible table, partitioned your database files and even thrown hardware at it and you still have issues, then NoSQL might be your salvation. Otherwise, stick to what everybody else is using.
...So the 5 people who still own Nokias will be able to print their own phone cases? Brilliant!