SCALE 8x: Relational vs. non-relational

Posted Mar 5, 2010 6:03 UTC (Fri) by skissane (subscriber, #38675)
Parent article: SCALE 8x: Relational vs. non-relational

SQL is just a query language. You can query anything you want with SQL, if you are willing to write the required code - a SQL parser, and code to execute the queries.

Likewise, any query language you want, you can use to query a SQL database. Once more, you just need to write the parser for your favourite query language, and some code to execute it.

In both cases, you may be able to reuse the target systems query engine to some extent, but may need to supplement it with your own code in some cases. For example, if I want to map SQL to LDAP, LDAP has equivalents to SELECT, FROM, WHERE, ORDER BY (if I use the sort control); but LDAP has no equivalents to JOIN or aggregates, so you'd have to write your own code for those.

SQL is not my favourite language -- if I was designing it, I would make the syntax much less COBOL-ish. I think its a pity we don't use something like QUEL or Tutorial D or BS12's query language. On the other hand, its the industry standard.

But please, no more trying to distinguish databases based on whether they support SQL or not. Any database can support SQL, or any other query language you want -- at most, its just a question of whether the database has that support builtin, or if you have to build it yourself. Its just an interface issue.

And also, too many people attack "relational" databases when they really mean to attack various real world implementations of relational theory. Most of their gripes are really with the implementations rather than the theory, and often the solution is not to junk the theory, but to improve the accuracy of its implementations.

SCALE 8x: Relational vs. non-relational

Posted Mar 7, 2010 14:17 UTC (Sun) by kleptog (subscriber, #1183) [Link] (2 responses)

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