Today on Read Write/Web, one of my favorite blogs, is an article that essentially mirrors my thoughts on relational databases and the semantic web.
Also, when I posted the original article, someone who seems to be a part of the W3 team working on the semantic web, referenced my original piece in a posting on the related W3 mailing list. He was using it to bolster his argument that the semantic web technologies are too complicated for mainstream developers, which is a core part of my argument.
This is a subject area that I and members of my team have been thinking about and working on for some time. It is always fun to see independent confirmation of the relevance of your work.
Don't know if you read Curt Monash's blog - he's just posted a great series on how the enterprise RDBMS landscape is changing. Part of his point is that for some applications, relational is no longer cutting it, and even within relational a lot of specialization is starting to emerge.
ReplyDeleteThanks Mark. I hadnt been familar with Curt's blog, but I enjoyed the series. This is fun. Its interesting to be at the early stages of something that other people are starting to talk about. I'll have to write more about this.
ReplyDeleteThere's plenty of life in RDB! You seem to be singling out the wrong culprit. Quote:
ReplyDelete"the relational database [sic - I think you mean RDBMS] isn’t even particularly good at adding new types of objects to the database"
That may or may not be true of particular DBMS products. Why should it be a limitation of the relational database model though? It seems to me that there is no such limitation implied by the model itself. So I think you have made a case for improving current DBMS software, but I don't see any objection at all to relational databases per se.
In the interests of accuracy it also needs to be stated that Oracle, MySQL, SQL Server, etc are not relational. They are all based on SQL - SQL being a flawed and incomplete imitation of the relational model. Have you considered that the problems you refer to may stem from the fact that they do NOT implement that model?
DavidP,
ReplyDeleteI am sure you are much more learned than me about the various technologies in the market and are aware of relational databases that do not suffer from the problems I describe. Whatever those thinly publicized products are, I am not talking about those.
That said, it is very hard to imagine a product that operates using relational theory that does not have the problems I am talking about. Fundamentally, linking fields to objects as opposed to objects to objects creates problems that I, personally, cant imagine being resolved in the relational model. The idea that pointers are stored in records is the cause of the problem, and I cant imagine *any* relational database solving the problems of which I speak and still being relational because this pointer in record assumption is at the core of the relational calculus and algebra.
There are no pointers in relational theory !! And no "linking" either. RM was designed to banish pointers altogether.
ReplyDeleteALL information in RM is values for attributes within tuples.
You may be in danger of making what Chris Date calls "The Second Great Blunder" so check out:
http://www.amazon.com/Databases-Types-Relational-Model-3rd/dp/0321399420/ref=pd_bbs_1?ie=UTF8&s=books
DavidP,
ReplyDeleteYou are confusing the word "pointer" in a navigational sense, and the word pointer, as I mean it, here in a generic sense.
Relational databases absolutely have pointers. They are called foreign keys. And having foreign keys (i.e. a field in one record that "points to" another record) is a pointer. You can't to joins without foreign keys.
I guess we'll have to agree to differ because every statement in your previous comment is wrong. At least according to every authority I know on the subject.
ReplyDeleteIf you are under the illusion that you can't do joins without foreign keys then you have apparently never used either SQL or relational algebra because that is demonstrably false.
Regards, D.
DavidP,
ReplyDeleteYou are right that you can do joins on any field in a db without it being a foreign key. Its just generally not very useful and considered bad form re: normalization. If you have invoices and you have customers, explain how you link these things without some kind of pointer (foreign key) and then do joins between them.
It sounds very much like you don't really think in real world practical terms. You're hung up on jargon an yet are not really seemingly able to address the core argument, which though poorly executed, is the purpose of the work of Tim Berners-lee and the semantic web folks. I guess your argument is they were dumb to think something else was needed. That said, I would love to hear *specifics* about how the kinds of problems that I am talking about and the w3c is trying (poorly) to solve. Is it all just a figment of our imaginations? If so please enlighten us.
I think you already answered your own question about the specifics of joining invoices and customers. All that is required is that your database (whether relational or not) contains relevant propositions about customer and invoice. In RM, propositions are represented by tuples and in RDF for example they are represented by nodes.
ReplyDeleteForeign keys are integrity constraints. Naturally RDF and other data models support integrity constraints too. I'm not sure why you see integrity constraints as an issue here.
I'm also not aware that RDBMS is a "problem" that W3C have set out to solve at all. In fact Berners-Lee says:
"one of the main driving forces for the Semantic web, has always been the expression, on the Web, of the vast amount of relational database information in a way that can be processsed by machines."
In other words what's he's concerned with is a model of data *interchange*, not data management. To borrow an analogy from Fabian Pascal: you should not expect the data interchange tail to be wagging the data management dog.
I dunno. The cynical and slightly battered experienced IT professional in me says anybody who claims 1 technology is better than another (or 1 is dying for instance) is just pushing an agenda or commenting from their own (limited) experienced point of view.
ReplyDelete(and for that matter to fully declare my interests, I'm an Oracle specialist)
RDBMSs are here to stay for a long time yet thanks to their massive market penetration and the vendors are quite willing to change their product to whatever customers want to chase the money. A minimal life estimate on RDBMSs would be 20 years, but I'd be willing to bet 50 years and more. (It's hard to quantify because I left my IT crystal ball at home)
Any allusion that RDBMSs are "dying" is overstating the fact given the above. I'm 32 and with another 50 years in me (I hope!), dying is not a word I'd like to use just yet. However you've picked a word that has too many negative connotations. Maybe a less emotive heading would be "what will eventually replace the RDBMS?"
Yeah yeah, I'm being picky and I know that to attract a good blog readership you need to write such headings, but it doesn't mean the 2 second sound-bite heading really conveys what's happening.
CM.
OOP is dying quicklier than RDMS.
ReplyDelete