A few months ago, when SPARQL made it up to Candidate Recommendation at the W3C, the announcement elicited considerable discussion on the techie forum /. A common sentiment expressed there was that RDF and SPARQL are just some weird fad, and that relational tables are here to stay. In ten years, we'll still be coding in SQL, and nobody will remember what RDF stands for.
This may well be true; after all, we all know that technological superiority is not particularly well correlated with longevity. But I can't help but notice something that I thought was a passing trend, but seems to be more prevalent than I thought.
That is the trend of database designers out-foxing their relational models, so that they can have a more flexible schema.
Here's how it starts. You build a database schema. You design it to your current specs as you know them, e.g., the important parameters of your product lines, your selection criteria for candidates, the parameters of the analytics your business needs, etc.
Then something changes - new analytics, new product lines and features, more criteria become relevant, etc. So you are faced with a puzzle - do I change my schema, and migrate? Do I hack in some information into an under-utilized field? Do I ignore the business changes? None of these options are nice.
So, the forward-thinking database architect comes up with a novel idea. Let's have a table that indexes all the parameters for a product/candidate/analytic etc. Now, I can add new parameters just by adding rows to a table. In the relational model, it is easy to add rows, difficult to add columns.
The reaction to this by your database buddies is incredulity at first. They think you are joking. Then they ask how you are going to query it - and you have a complex, but workable answer to that. Then they ask how efficient those queries are. This is more problematic, but you have a plan.
One DBA told me that they nicknamed this solution as "Stealth Columns"; other projects were scrapped at this point. I had one such DBA, when asked the "Can you efficiently query this?" turn to me and ask, "I'm hoping you can migrate this into a triple store and query it quickly. Right??"
This last fellow had caught on. He realized that he was not the first to come up with this solution, nor the last. And that there was a reason why it had not caught on as standard practice - because it was not workable in the long term. The tricks he had to play with his queries made his team's experience in indexing RDBs useless. He basically had to re-train them, in a solution that nobody else had got to work well.
RDF is an elegant solution to this problem, and a standard one. One for which someone else is doing the hard work of optimizing. One for which it is possible to find people educated in how to use it (not as many as are currently educated in SQL, but a lot more than know how to manage any particular home-grown solution). And RDF resolves all the issues that brought our DBA to this point; it is just as easy to add columns as rows. Schema are as flexible as data.
The governance of such a system poses new problems that a relational model does not; after all, now that you can extend the schema, there are parts of the system that were once sacrosanct that now can be modified. But this problem was there for the home-grown solution, too; the only barrier there was that the team was so confused by the model that nobody could change it at all. The governance issues are part of any solution to the flexible schema problem; if your schema is flexible, then you'll need some way to manage that flexibility.
