Not Relational Enough

Two recent articles about XML and database technology. One of the FAQs about Kowari is in respect to relational databases. Taking the pedantic view, the two databases mentioned are not relational but SQL. I've previously posted links about XML management systems too.

In, XML, the New Database Heresy "One of the major benefits of using XML in relational databases is that it is a lot easier to deal with fluid schemas or data with sparse entries with XML. When the shape of the data tends to change or is not fixed the relational model is simply not designed to deal with this. Constantly changing your database schema is simply not feasible and there is no easy way to provide the extensibility of XML where one can say "after the X element, any element from any namespace can appear". How would one describe the capacity to store “any data” in a traditional relational database without resorting to an opaque blob?

I do tend to agree that some people are going overboard and trying to model their data hierarchically instead of relationally which experience has thought us is a bad idea."

Edd Dumbill wrote in, Ron Bourret on XML and databases "My guess is that everything will pick up on this front in a year or two, with companies moving towards what I consider the holy grail of XML support in relational databases: native storage behind a first-class XML data type, XQuery support with extensions for (a) including relational data or SQL queries and (b) updates, SQL/XML support with extensions for embedded XQuery queries, and support for JSR 225 (see below)."

One of the aspects we've found in implementing TKS/Kowari was that it pays to stick closely to the relational model. Everything comes down to tuples and I think that the problems with putting RDF on top of SQL database is that they aren't relational or "relational enough" (whatever that means).

Actually, the DAWG is asking for comments, maybe ensuring that the queries are expressed in relational algebra. That should prevent things like NULL getting in there.