Cart
[Home] [By Thread] [By Date] [Recent Entries]
I just picked up on the database decision tree thread. Life has been hectic, but boy was I remiss. Hope it's not too late to throw my 2 cents in- you know I'm going to anyway... I was generally really impressed by the discussion, but I think there might be an aspect to it that is missing. It's a little more "Zen of XML" oriented, but I think it is worth considering. XML is a carrier of data plus context, data plus metadata. This is obvious, but is often lost in document design. When I look at a lot of schemas out there these days, they are often blatantly influenced by an underlying relational mentality. This is not a bad thing if your eventual target is an existing relational database. My question is this: If the ersistence mechanism used were not relational, but if it treated XML as XML in a very fundamental way- symmetrically handling data and metadata, for example- would schema design change in any fundamental ways, particularly for "new" data? We tend to put the schema before the persistence choice. If we did it the other way around, would anything change? Referential integrity, for example, between such mundane objects as customers and purchase orders might be accomodated by treating the customer and his list of POs as a single doc. Or, if the implementation is efficient enough in terms of data footprint, by replicating customer data on each PO. We tend to shape our data to fit our container, not the other way around. In general, this was because we had no choice. Many a wonderful object model has gone astray when tossed upon the shoals of RDBMS design constraints. (O/R mapping tools helped, but the solution was less than satisfactory and a real pain to maintain.) The ability to persist and manage XML "natively" may now give us the choice. The analogy with OODBMS is not inappropriate, but XML has the advantage of being the preferred transport mechanism as well, and old-style OODBMS still constrained schema. Does this make any sense? Linda
|
