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

[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 ...

near drives me to distraction.  SQL-like syntax?  Why would I want to learn another SQL syntax  ?  And if it's NoSQL, what is this SQL-like syntax API doing there  ?

I'm confused.  I'm really confused  .

[Ath]

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

[barney]

Ouch  !  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.]

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.

[wraith808]

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.

An good implementation of No SQL is  MongoDB.  They actually have a really cool parser and examples there.  And I think that the not ready for enterprise primetime label really applies if you try to apply it to situations in which it is not meant for.  Most non-commercial solutions are not a good match- it is for IMO more consumptive uses of data, i.e. ecommerce and such.  The MongoDB website has use cases that spell that out, and examples of production deployment- and most of them mirror that ideology (though I can't see why there is a SAP deployment?  That would seem crazy to me).

[Ath]

ever expanding collections of non-structured "stuff" (images, loose document collections, tweets, messages, etc.)

So in fact Lotus Notes (now owned by IBM) was in fact (one of) the first NoSQL storage systems, way back then

[wraith808]

ever expanding collections of non-structured "stuff" (images, loose document collections, tweets, messages, etc.)

So in fact Lotus Notes (now owned by IBM) was in fact (one of) the first NoSQL storage systems, way back then

Ick.  Not exactly.  I remember my Lotus Notes days.  It was like a mega-access more than NoSQL in my recollection.

[barney]

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..

I think that hits the meat of the situation.  I could maybe see a NoSQL or even non-RDBMS, system for something like the entire school system of Chicago, Dallas, Houston, New York, et. al., but no way can I see it worth the effort and grief for a single school.

I think my lady has an idea of combining all school databases into one (1) [relatively] massive system.  I also think she doesn't have enough mass extant to be worth the effort.  I've pulled down a few docs on the subject - nothing clear, unfortunately - that I think I'll giver her along with a [redacted] printout of this topic.  That may be enough to dissuade her, or at least persuade her that she needs to grow a bit, first  .

As a side note I still have not seen anything close to a guideline as to when it might be advisable to switch.  That would be nice to have.  You know how it is, I suspect.  When you work for someone, especially gratis, a 3rd-party opinion is almost always better than your own  .

[wraith808]

I think that hits the meat of the situation.  I could maybe see a NoSQL or even non-RDBMS, system for something like the entire school system of Chicago, Dallas, Houston, New York, et. al., but no way can I see it worth the effort and grief for a single school.

I don't even see it for that.  Non-Transactional with limited relational capabilities is the key.  If you need relational data (and from at least my experience with school databases, you do) or transactions (same caveat) then this isn't really the way to go IMO.

[barney]

I don't even see it for that.  Non-Transactional with limited relational capabilities is the key.  If you need relational data (and from at least my experience with school databases, you do) or transactions (same caveat) then this isn't really the way to go IMO.

Total agreement.  I thought that from the start.  (That's why I said maybe.  It would require a total rethink of the system, and if applied, replace it with something terribly less effective.)  But when a client - or a boss/manager/supervisor - gets an idea crossways in their head  ... the worker bees have to set the drones straight  .