Re:A Comprehensive Guide to Moving from SQL to RethinkDB
by mberning on Tuesday April 07, 2015 @12:21PM
(#9335091)
I think many problems could be solved equally well using either technology IF you understand the strengths and weaknesses of each technology and implement them appropriately. It just so happens that knowledge of how to use a RDBMS appropriately is MUCH more common than document databases.
Re:A Comprehensive Guide to Moving from SQL to RethinkDB
by ppj606 on Tuesday April 07, 2015 @12:26PM
(#9335139)
With the rise of realtime applications I'd argue that the situations for using NoSQL for the common project are growing.
I think the author of the post has made a good point, that many seem to forget - it is always a trade-off whichever tool you use.
Re:A Comprehensive Guide to Moving from SQL to RethinkDB
by moe on Tuesday April 07, 2015 @12:35PM
(#9335218)
With the rise of realtime applications
What does "realtime" have to do with the datastore?
Re:A Comprehensive Guide to Moving from SQL to RethinkDB
by ppj606 on Tuesday April 07, 2015 @01:14PM
(#9335517)
The usage and access of data in your data store when building a realtime application. If you were building a chat-app these days you are given a number of very easy to adopt (minimal complexity/edge cases) NoSQL solutions - Firebase, Parse, RethinkDB.
Whereas with SQL you have the option of using cache layers (which you could say is NoSQL anyway), message queues, naive timely polling and log monitoring.
With NoSQL the solutions are just simpler. For example Firebase has a tutorial for creating a real-time chat [1] - it takes 5 minutes.
I've seen far, far more cases of document databases being used in situations that are entirely inappropriate, than in situations where they are ideally suited.
I'd argue that the situations in which it's a good choice to use a document database are pretty rare, and that you're almost always better off using a bog-standard relational database.