As most of you know I have been engaged in discussion, triggered by my Death Of The Relational Database article, about next generation database ideas. A theme has continued to pop up that I do believe has some merit and so I want to try to explore it. Unfortunately as I write this, I am sitting at the Virgin America terminal at JFK in New York, headed to Los Angeles. As such, I don’t have as much time as I usually do to to flesh all of this out.
In any case, the point I want to make here is that many people are saying that relational does not necessarily mean SQL. And indeed this is true. Relational refers to what really is a mathematical framework for mapping tables of data.
However, certainly in colloquial terms, relational database *does* mean SQL. There are precious few people that, when they think of solving a multi-table problem do no think of MySQL, Postgres, Oracle, et. al.
Perhaps it is foolish that people think this way, but I am not familiar with any other category of commercial grade relational products that are on par with these types of SQL without being SQL. Note, I am not saying that they do not exist. Though I am curious if they do exist, why so few people know of or use them.
In that regard, over at Hacker News, there has been a *great* discussion about these issues. One commenter, edw519 provided a list of links to products that are relational but as he describes them are not rigid in the traditional SQL database kind of way, that perhaps address some of the issues I am raising. I have listed the url’s below.
http://www-306.ibm.com/software/data/u2/
http://www.jbase.com/
http://www.rainingdata.com/products/dbms/index.html
http://www.revelation.com/
It would be great to discuss some of these products. I will be taking a look over the next few days, but since there seem to be so many of you that “get” what we are talking about here, I would love to hear in comments some of the pros and cons of these referenced applications.
Also note that there are quite a few products that I know *do* do what we are talking about in the Death of the Relational Database article. However none of these are relational. So although we are creating a product in this general space, we are not the first people to think that this area is important, and my intent here is to also discuss other approaches with some combination of academic rigor, and conversational practicality. In the coming weeks I will try to begin conversations about some of the products I am aware of as well as some of the things people are working on that I have been made aware of through this blog.
And so this is a call to action for all relational != SQL zealots and anyone else that wants to weigh in. How far do relational tools go without SQL, and are they scalable, friendly and generally useful? Most importantly, do they solve the same kinds of problems I describe in Death Of The Relational Database?
Thursday, March 27, 2008
Subscribe to:
Post Comments (Atom)
3 comments:
Hi Hank,
I read your two posts about this topic, but I haven't had time to read all the comments, so I haven't followed all of the discussion that arose, but at least I scanned them.
I just want to give you some information about a topic that arose in the comments on your other blog post, so that you become aware of a new tool for your research :)
I would think that we should make a distinction between the "relational data model" and RDBMS. Here is why I make this distinction: most RDF triple store implementations are built on top of RDBMS. But clearly, the RDF data model is completely different from the relational data model.
What is happening? In systems such as Virtuoso (Virtuoso is both a RDBMS and a RDF triple store, and it is developed by OpenLink Software Inc.), you have a SPARQL parser (SPARQL is the query language to query RDF graphs) that convert SPARQL queries into optimized SQL queries. These queries are sent to a 4-column table. The four columns are: (1) graph (2) subject-of-the-triple (3) predicate-of-the-triple (4) object-of-the-triple. Then you have some indexes on these columns to make things performant.
So, this means that a RDF triple store is, basically, a 4-column table with a couple of indexes and SPARQL queries that are translated to SQL queries.
Considering this, are RDBMS then dying? I don't think so. Is the relational data model dying? More than likely, but given legacy practice it will be a slow death :).
Also you said: "Unfortunately, the semantic web is proof that while a little geek is good, but too much geek is, well, too much geek. The problem is that the people that created the semantic web were just way too smart. In fact if you read even the watered down Wikipedia description of the semantic web, it sounds like useless abstract gobbledygook."
Sorry, but I don't agree with that. It is not a question of geekness or smartness, but a difference from what people are used to and already know. These things can be: tools, concepts, etc. While there is definitely some poor language and communication around many Semantic Web things, there are also new concepts, new tools, new ways to do things, etc.
As a thought experiment, imagine that the semantic Web had preceeded RDB and RDBMS. Then, today, what would be familiar would be graphs, graphs and network theory, triple stores, graph query languages, how to create ontologies and manage such information. Now, if presented with new relational RDB constructs such as tables and joins and stored procedures, all of that might look pretty geeky too.
To be sure we need better and clearer language. But we should separate that question from the question of what people know, and what they are used to in their daily life.
However I do agree, that presently, information about these concepts and principles (semweb & related stuff) are sparse and hard to understand. I daily fight against that, and we, at Zitgist (Zitgist.com) and OpenLink (Openlinksw.com) are working to make things simpler, to make concepts clearer, to create tools and tutorials to demystify things so that people can leverage these new concepts, principles and tools so that they can add even more value to their products and services.
You speak clearly and directly. We invite you to add your voice to the chorus. :)
Thanks!
Take care,
Fred
The databases you heard about on Hacker News are all pretty much the same thing: what's left of the Pick-style multivalued database tools that pre-date relational DBMSs and died out like dinosaurs back in the 1980s. They now occupy an Amiga-like niche, still used and promoted by a small group of die-hard users, but not taken very seriously.
Relational databases don't dominate because nothing existed before them; RDBMSs have pretty much replaced and obsoleted every other type of database architecture, and there were quite a few. There's probably little to be gained looking back in time at hierarchical or hash-based multivalued databases. If I can paraphrase Churchill, relational databases may not be the best database management tool, but all of the others are so much worse.
I posted a longer reply on Hacker News:
http://news.ycombinator.com/item?id=149786
Pick type systems are a dead end.
Don't go there.
Post a Comment