Under Constru

http://slashdot.org/topic/bi/sql-vs-nosql-which-is-better/

This article talks about potential reasons to go with a NoSql database. It gives more specific scenarios than usual such that there is more to analyze.

There seem to be two primary arguments for sometimes going with a NoSql database:

* The need to avoid "Join" look-ups for commonly-associated information

* The need to have "non-tabular" or semi-tabular ("low structure") data.

A scenario the author gives is contact info associated with a given user. For example, a given user may have multiple cell-phone contacts, a fax number, a personal site URL, a Twitter contact, etc. This issue is discussed in ContactAndAddressModels.

---------
'''Avoiding Joins'''

I agree that if two kinds of info is commonly associated in used in conjunction, then avoiding the JOIN process can indeed speed things up. However, that '''in theory''' should be a machine-level optimization choice, not a schema-design issue nor a query writing issue. One could tweak the RDBMS to actually store closely-related items together on disk. Thus, the "user info" table and the "contact detail" table(s) could have related records close to one another.

One typically envisions one table being physically separate from another on disk, but there is nothing preventing them being "integrated". Of course, there will be trade-offs in terms of other query patterns being slower, and a more complex RDBMS to allow such such physical interweaving. (I couldn't name an RDBMS product with that ability off the top of my head, right now.) -t

-----------
'''Low-Structured Data'''

I'm not convinced that contact details, such as multiple phones, fax, Twitter, FaceBook accounts, etc. need a dedicated table for each "type". Something akin to DynamicRelational would improve the flexibility of RDBMS-style tools, but still I have not seen that it would significantly help in this case. We could have a "static" table similar to:

 contact_details (table)
 -------------
 customer_ref    // user "ID" foreign key
 rank            // priority of contact
 contact_type    // Ex: phone, Twitter, email, URL, etc.
 contact_value   // the phone number, email address, URL, etc.
 notes

--top

----
"SQL vs. NoSQL: Which Is Better?"

As a user of both SQL and NoSQL (and a developer/user of true relational DBMSs) I find that question to be sillier than "Hammer vs. Screwdriver: Which Is Better?"

Using '''both''' the RelationalModel ''and'' NoSQL, as and when appropriate, makes sense.  Use the right tool for the job.

Using contact lists to illustrate "low structure" demonstrates the author's lack of understanding.  Contact lists are not "low structure" -- or at least not any lower than innumerable other scenarios for which SQL is appropriate -- and are hardly a justification for NoSQL.  However, running -- for example -- hundreds of concurrent ad-hoc text searches on multi-petabyte document collections is where NoSQL shines, and where there is (rightfully) no reasonable SQL (or RelationalModel) equivalent.  Can you do what Apache Lucene does, as easily, in SQL?

''Some RDBMS have reg-ex searching. Whether they can compete with document-specific search engines on the high-end, probably not. A specific tool for a specific kind of "thing" is probably better than a general-purpose tool for the same thing.''