4 ms·

Use a "NoSQL" database when you have very large amounts of data (so you need 1000s of separate disks) or large volumes of queries (so you need a 1000s of separa

Use a "NoSQL" database when you have very large amounts of data (so you need 1000s of separate disks) or large volumes of queries (so you need a 1000s of separate servers). Otherwise MySQL, SQL Server, Oracle etc. is probably fine. NoSQL has an learning and 'new technology' overhead that isn't worth paying unless the pain of using traditional databases is too high. Don't forget SQLLite too - nice for the very small applications.

hugofirth 12y ago
Its not necessarily just about the quantity of data. What you want to do with the data (the queries you want to run) should play an important role in deciding your database. For example: a query workload with lots of deep traversals would make a graph database attractive even for a relatively small dataset.
nickik 12y ago
There are many other reasons to use "NoSQL" not just big data. Sure MySQL would probebly be fine, but somebody might just think that RandomDB might just be nicer to use, easier to set up, closer to your data model or any number of other things. > NoSQL has an learning and 'new technology' overhead that isn't worth paying unless the pain of using traditional databases is too high. You say that as if everybody is born with knowlage of SQL. I would of course teach SQL to every new programmer still but im just point out that is not the best argument.
- bbcbasic 12y ago
  Support for tooling, ease of hiring both programmers who are familiar with querying and DBAs is much better on relational. The pain caused by relational being a 'bad fit' needs to be pretty high to consider NoSQL in my opinion. Except for hobby projects (I did some CouchDB stuff in my spare time for the thrill, but MySQL would have been adequate.) True, noone is born with SQL knowledge (learning to breath is the first priority). However stick your ad up for an experienced Cassandra DBA and then an experienced Oracle DBA and see how you do.

hugofirth 12y ago

Its not necessarily just about the quantity of data. What you want to do with the data (the queries you want to run) should play an important role in deciding your database. For example: a query workload with lots of deep traversals would make a graph database attractive even for a relatively small dataset.

nickik 12y ago

There are many other reasons to use "NoSQL" not just big data. Sure MySQL would probebly be fine, but somebody might just think that RandomDB might just be nicer to use, easier to set up, closer to your data model or any number of other things. > NoSQL has an learning and 'new technology' overhead that isn't worth paying unless the pain of using traditional databases is too high. You say that as if everybody is born with knowlage of SQL. I would of course teach SQL to every new programmer still but im just point out that is not the best argument.

bbcbasic 12y ago
Support for tooling, ease of hiring both programmers who are familiar with querying and DBAs is much better on relational. The pain caused by relational being a 'bad fit' needs to be pretty high to consider NoSQL in my opinion. Except for hobby projects (I did some CouchDB stuff in my spare time for the thrill, but MySQL would have been adequate.) True, noone is born with SQL knowledge (learning to breath is the first priority). However stick your ad up for an experienced Cassandra DBA and then an experienced Oracle DBA and see how you do.