MORE ON XML
with Fabian Pascal

 

 

 

From: SM

To: Editor

 

Recently a suggestion was made to have a look at an Infoworld "analysis" article (Databases flex their XML), that describes the XML feature sets and capabilities of several current DBMSs.

 

Unfortunately, what came to mind in having a look at the article was that its premise, as stated in the opening sentence, "If you could do one thing to improve integration and automate processes with customers and business partners, it would be to implement XML," appears to be dubious at best.

 

However, one quote in particular, What does a fashionable XML database provide?, seemed a likely, and perhaps fitting quote of the week candidate. The italicized text below is from the article, (non-italicized comments are mine).

 

What does a fashionable XML database provide? Four basic functions: the ability to consume, store, search, and generate XML. The extent to which the database supports these functions and the methods it uses to accomplish them are what make for a successful implementation of XML in a database.

 

Then, apparently, implementing an "XML database" is primarily about being fashionable. Fair enough, but to continue...

 

Relational databases and XML documents are both powerful ways to represent relationships among data, but they're powerful in different ways. For example, querying on a patient ID number in a relational database may allow you to quickly find the dates a certain patient visited the hospital, the conditions he was diagnosed with, and the treatments he was given. But it likely won't help you determine which treatments were provided for which conditions or what times the treatments took place, nor will it give you other useful information that XML versions of these records could provide.

 

Is there something missing here? Assuming one is dealing with an underlying relational database design for various sorts of common hospital settings - wouldn't the sort of querying requirement described for patient information likely simply come to a matter of joins between various appropriate tables? {The results being further constrained to specific key values that correspond to a given patient)?}

 

In terms of "XML records", wouldn't the efficiency of the sort of querying requirement described actually be completely dependent upon the specific design of the "XML records" in question...?  {What if, for example, each "XML record" has doctors, or diagnosed conditions, or clinical departments at the root level, (rather than patient information); and each patient may have seen many different doctors, in different departments, and been diagnosed with many different conditions?}

 

 

From: Fabian Pascal

To: SM

 

You are too polite and understated.

 

 

Ed. Note: I’ve written several articles demonstrating that trade journalists and editors have little clue about the subject matters they cover, and I deplored the fact that because of that they simply regurgitate vendor or “expert” claims/press releases, without ability to interact with the material and assess its accuracy, validity or relevance. This is all part of the dumbing down process occurring in the industry, academia and society as a whole.

 

 

Posted 07/30/04