Noodling on NoSQL: Thoughts on Multi-Structured Data Management
DEC 26, 2012 9:01am ET

Related Links

Many Enterprises Fill Skills Gap with ‘Citizen Developers’
August 27, 2014
Building an Advanced-Analytics Center of Excellence
August 25, 2014
Unleashing the Value of Advanced Analytics in Insurance
August 25, 2014

Web Seminars

Why Data Virtualization Can Save the Data Warehouse
September 17, 2014
Essential Guide to Using Data Virtualization for Big Data Analytics
September 24, 2014
blog

What Does NoSQL Mean To You?

Print
Reprints
Email

I am not such a fan of definitive definitions. For example, “something MUST be A, B and C to be XYZ” would not be one of my favorite concepts. While it is very reassuring to have this black and white structure on definition, the restrictions don’t allow for future growth. 

Get access to this article and thousands more...

All Information Management articles are archived after 7 days. REGISTER NOW for unlimited access to all recently archived articles, as well as thousands of searchable stories. Registered Members also gain access to:

  • Full access to information-management.com including all searchable archived content
  • Exclusive E-Newsletters delivering the latest headlines to your inbox
  • Access to White Papers, Web Seminars, and Blog Discussions
  • Discounts to upcoming conferences & events
  • Uninterrupted access to all sponsored content, and MORE!

Already Registered?

Advertisement

Comments (2)
I'll give you the "no" and "not only" definitions as they do make sense. Personally I prefer to call it "schema-less" as a catch-all.

And I must point out that you left one of the biggest, and perhaps oldest, of them all off your list -- IBM Notes (formerly Lotus Notes). It has been around for 23 years (since 1989) and has a history going back another 15 or so prior to that! It is a document store, in the vein of Mongo and Couch.

Posted by Brad H | Monday, December 31 2012 at 8:16AM ET
So SQL is a set-based language for data retrieval. Whether SQL or something else is the "right" answer all comes down (as it always does) to what is required as the end result. Choose the appropriate tool for the job.

If highly structured data is to be managed then an implementation based on the Relational Model (and hence an SQL approach to retrieval) is arguably suitable.

If "unstructured" data (whatever that means) is to be managed then that should not automatically mean that a relational/SQL approach should be ignored, rather that the most appropriate model should be considered from a wider pool of models. That may or may not be an SQL approach or something else.

Being an advocate of the Relational Model (with a strong background in it) I would be the first to argue that the Relational Model should not be the automatic answer to everything, just as a NoSQL solution should not become the automatic answer to everything.

Is this any different to what has been going on ever since SQL was invented? I don't think so, I think it is just giving it a name.

Posted by Andrew D | Thursday, January 03 2013 at 4:57AM ET
Add Your Comments:
You must be registered to post a comment.
Not Registered?
You must be registered to post a comment. Click here to register.
Already registered? Log in here
Please note you must now log in with your email address and password.
Twitter
Facebook
LinkedIn
Login  |  My Account  |  White Papers  |  Web Seminars  |  Events |  Newsletters |  eBooks
FOLLOW US
Please note you must now log in with your email address and password.