Main Area and Open Discussion > General Software Discussion

In search of ... the whys and wherefores of NoSQL

(1/3) > >>

barney:
Apparently I'm dimmer than usual tonight.  Just started reading about NoSQL databases (been intending to for a while, but life keeps getting in the way ;)), and I just don't get it  :(.

For instance, this statement
NoSQL operations may be implemented over these APIs:
     • SQLQuery - allows querying a space using a SQL-like
        syntax and regular expressions ...
--- End quote ---
near drives me to distraction.  SQL-like syntax?  Why would I want to learn another SQL syntax  :huh:?  And if it's NoSQL, what is this SQL-like syntax API doing there  :huh:?

I'm confused.  I'm really confused  :-\ :-\ :-\.

Ath:
Maybe this is just for you (and others)? NoSQL for Dummies

barney:
Ouch  :stars:!  That raises more questions than it answers.

OK, I recognize that NoSQL is not No SQL, although I do wish it had been given a better cognomen.  That much, I knew.  What I don't know, as a jump-off point [ferinstance], is when to consider such a database.  Another question would be, "Just how many such entities are there?"  (Ath's link quoted four (4) by way of example.)  Do I roll my own?  Where can I find guidelines, summaries, comparisons:  I need to know, should I adopt such an approach, which database(s) would best fit my purposes.

It strikes me that the database arena is becoming as forked as the *nix arena, with every element having its own fan base, and no consensus, much less clear choice.

[Sidebar.  This topic has come about because of a school for which I do some pro bono publico work.  The administrator for my area asked me about NoSQL, whether it would hold any practical advantage for the school.  Since the work is local to the school, I'd think not, but I told her I would do some research.  So far, that research has revealed a morass, no real organization/definition at all.]

Renegade:
Maybe I can help dumb this down some more. :) (As I'm the first to need it...)

If you know that you will break your RDBMS at some point, then look at NOSQL. If you won't break your RDBMS, then forget it.

NOSQL is for MASSIVE systems. That's all. There's no reason to use it or even look at it for most purposes. You're far better off going with standard stuff like MySQL, SQL Server, etc. There's more information on them and they're easier to use because of the rich toolkits for them.

40hz:
[Sidebar.  This topic has come about because of a school for which I do some pro bono publico work.  The administrator for my area asked me about NoSQL, whether it would hold any practical advantage for the school.  Since the work is local to the school, I'd think not, but I told her I would do some research.  So far, that research has revealed a morass, no real organization/definition at all.]
-barney (June 19, 2012, 08:18 AM)
--- End quote ---

I've done some research into non-RDBMS databases for a client. (I prefer non-RDBMS to NoSQL since there are at least 3 very different technologies calling themselves NoSQL right now.) I can save your school administrator some work. What I found: not ready for enterprise primetime except in very specific and specialized circumstances. For day to day general database requirements (i.e. any data that can easily be structured as a table - which is to say most data), RDBMS is still the best current choice.

NoSQL may work well for gangling and ever expanding collections of non-structured "stuff" (images, loose document collections, tweets, messages, etc.) running under some form of cloud backend. But for what most organizations have for, and need to do with, their data, it's far less an advantage and much more of a risk to drop their relational databases. At least right now.

Navigation

[0] Message Index

[#] Next page