SCALE 8x: Relational vs. non-relational

Posted Mar 7, 2010 14:17 UTC (Sun) by kleptog (subscriber, #1183)
In reply to: SCALE 8x: Relational vs. non-relational by skissane
Parent article: SCALE 8x: Relational vs. non-relational

That's not entirely true. SQL has concepts like "tables", "columns" and "rows" which, if your database doesn't have them, is going to make it really hard to make SQL function at all. (SQL assumes a fairly rigid structure)

For example, suppose your database consists of a objects with attributes, dynamically created, which can contains references to other objects, not necessarily of the same types. Maybe there are no "types" at all and all objects are exactly as they come. They may reference other objects arbitrarily.

While you might try to make something that looks like SQL for such a database, but it's unlikely to be practical.

I think NoSQL should be reserved for databases which don't follow the relational model at all, and thus are unsuitable for SQL even if you wanted it to.

SCALE 8x: Relational vs. non-relational

Posted Mar 7, 2010 16:53 UTC (Sun) by bronson (subscriber, #4806) [Link] (1 responses)

Or, what if your queries don't easily translate into SQL's SELECT and UPDATE model?

I had this last year: the data itself fit perfectly into tables with foreign keys. Problem is, we were trying to allow marketing people to slice and dice it in fairly arbitrary ways, and their needs would change from week to week.

This was typical data warehouse-type stuff. Compute the monetary total of all orders for customers from this region. If that's above a value provided by marketing, then what's the average zip code and standard deviation for the remaining customers who have dogs, etc. (you get the idea)

I wish I had done the whole thing in MongoDB using map-reduce. I think it would have been a lot faster, both to develop and to run. I wouldn't have to spend as much time figuring out which indices, counter caches, and denormalization that would be needed to make this week's reports complete in time.

So, even if your data model is nicely tabular, that doesn't mean your usage patterns will be!

Regarding hierarchical RDBMS

Posted Mar 11, 2010 10:35 UTC (Thu) by gvy (guest, #11981) [Link]

I've met at least two bright examples of non-relational RDBMS which did shine where My|Pg or Ora just would not:

Daylight for cheminformatics just blew off whatever I could even primitively benchmark with mysql/postgresql back then (2001/2002) by *orders* in speed, not even trying to compare the exact problem domain value (e.g. fingerprints);
GT.M (remember MUMPS?) and temporal model users (whether in hospital IT or business) might have a good laugh with "If the data being stored has a life independent of the specific application and needs to be available to new applications down the road, SQL-relational is probably the right choice".
There was e.g. a discussion on sql.ru describing the details of a migration off a "legacy" hierarchical system to Java and Oracle -- which "doubled the performance" (forgetting to mention the need to go dual Xeon 51xx and external storage from something like dual Pentium with SCSI).

Basically, if you have to do things like "this attribute holds a value changing the *meaning* of that attribute", then you just reinvented a hierarchical database where adding another leaf might be less pain and overhead. And you might have wanted to look a bit wider. :)