Remembering the Future

on uses of XML: The bread-and-butter use cases remain what they have been: acquiring relational data from XML documents, transporting relational data as XML, and publishing relational data as XML. But Rys highlighted two emerging use cases that say interesting things about the way in which XML is bringing more fluidity to data management. The first example is what I'll call "expanding entities" -- that is, entities that are primarily modeled in SQL, but that have fluctuating sets of properties which are more conveniently handled in XML. The second example, Rys says, was a surprise to him. People are serializing CLR object data and storing it in XML columns. Given that Yukon directly supports CLR objects, why do that? Two reasons. First, they're limited to 8K -- that's the boundary, in the database, between normal and large objects. But perhaps more importantly, you have to register your .NET assemblies in the database; it's hard to evolve your objects there; and you can't mix types in a single column. With XML, Rys says, you might register an initial schema, but you can then add more schemas over time, and you can mix document types in a single column.

I find this last point -- on XML's role in the evolution of data -- to be especially interesting. Content management and data management have been converging for some time, but there hasn't been common ground on which practioners of these disciplines could meet. Now that enterprise databases are providing that common ground, we should start seeing all kinds of fruitful collaborations.

Topics: SQL | XML