This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

RDF vs. RDB

Stefan Tilkov,

Radovan Janecek, pointing to a post from Bill de hÓra, quotes this paragraph:

One of the advantages of storing an RDF representation in an RDBMS is that you’ll never (hardly ever?) need to make a schema change in the RDBMS - because the domain is not represented using tables - tables are solely used for storage of RDF triples.

I totally fail to get this. Why would you use an RDBMS in the first place, then?

I’ve recently become a big fan of good old relational databases. Any time I see some meta technology, I point to the appropriate layer in an RDBMS and point out that it’s already there, it’s tried and tested and hardened in 20 years, interoperable, interchangeable, available for free and for big money and there’s plenty of skilled people available … but this kind of usage seems to me like using one table for classes and one for objects (or rather, their attributes) and then pointing out how cool it is you never have to make schema changes :-)

On December 22, 2005 10:09 PM, Mark Baker said:

Yup, that’s the claim. What’s not being said though, is that there’s a huge tradeoff being made by making the schema immutable; data access optimization.

I should have a look to see what Oracle’s done with its RDF support, but AFAICT, the industry’s still got a ways to go with scalable RDF stores.

See also; http://esw.w3.org/topic/LargeTripleStores

On December 23, 2005 3:06 AM, Bill de hÓra said:

“Why would you use an RDBMS in the first place, then?”

Because you want indexing support and file/file-system independence, among other things, without having to write that infrastructure.

And yes, it is cool that you never (?) have to make schema changes - first chnaging databses is nightmare and second so is merging them (by extension if you have no schema chnages you have a a basis for merging. The engineering problem of getting these things is hard, but not as hard as integrating and staying flexible (imo). The arguments made here for an RDBMS - battle-hardened, scalable, market skils - replace RDBMS with Java, and it’s the same set of issues.

“What’s not being said though, is that there’s a huge tradeoff being made by making the schema immutable; data access optimization.”

Mmm, maybe not directly, but that’s part of what I’m saying. Hence the point about the order of magnitude increase in row count and engineering effort. And let’s be clear, “immutabilty” here means early typed.