Switching from a relational to a microcontent model
For the past week I've been writing about data structures and microcontent here, and planning the database architecture for my new Ruby-based blog code on my Ruby blog. It's interesting how two different streams of thought can influence each other. I've been building relational database applications since 1981, and I'm now thinking about the ways that a microcontent database model would affect a web-based application.
The basic difference between the relational and the microcontent model is flexibility and variability. A good relational database is designed with three things in mind: speed, speed, and speed. That means streamlining everything in terms of consistency. While relational databases can be modified relatively easily in terms of physical arrangement of data between files, trying to add a completely new data type can take some serious programming, and trying to adapt to a new data structure during run-time sounds suicidal.
If you want to buy into the microcontent model of individual packets of information, each of which can have different types of data, then you need to move to an object-based database, in which each item can have a unique internal structure. It is most likely that developers will use relational databases for quite some time to handle microcontent, but this will change as they start thinking about flows of individual data items instead of a structured set of normalized data tables.
Of course, someone will have to do the hard work of making a fast microcontent database. I'll be evaluating new object, xml-based, databases in the future. Oh boy, sounds like fun!
