RE: [xml-dev] XML Database Decision Tree?

["Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>]

> -----Original Message-----
> From: Magick, Brian [mailto:Brian.Magick@COMPAQ.com]
> Sent: Tuesday, October 30, 2001 2:34 PM
> To: Champion, Mike
> Cc: xml-dev@lists.xml.org
> Subject: RE: [xml-dev] XML Database Decision Tree?
> 
> 
> 
> <<I have a gut feeling that the typical
> developer can do a decent data model in XML more easily than he/she
> could do
> a decent normalized RDBMS model, but that's one for the Time Will Tell
> file.>>
> 
> I would caution that if your organization like mine is
> guided by a set of Data Architecture/Data Management standards,
> policies, best practices, and principles that this is still 
> best left to the data architect.  

Absolutely no disagreement here.  The canonical use case I'm talking about
for "XML database means not having to do a database design" is where you
have lots of XML data streams of different types coming in, and you don't
have the resources or even the requirements to do more than persist them
reliably and find specific instances later, e.g. during an audit or when
investigating a complaint.
Any mission-critical data, XML or otherwise, deserves careful professional
attention at design-time.

>  My point is that you typically
> create a data model for the entire RDBMS before you put it in
> production.  For XML your data models (Schemas) can adapt to 
> change in a Native XML database much easier, and your set of data models
is most
> likely always growing (introduction of new XML and associated 
> Schemas). Typically the Native XML database does not subscribe to the
concept of
> one data model to describe the entire database. 

Yes, I agree. The flexibility of an XML database system can be put to good
use in well-designed applications as well as exploited for ad hoc
applications.

>  Embrace this new paradigm shift, engage your Data
> Architects, and know that your XML is being architected in a way that
> supports the overall goals and principles of your companies data
> strategies.

Right!  Thanks for persisting and making this clear.