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

[David Lyon <david@globaltradedesk.com>]

?= <3549BAFD79A7D411A1CF00508B62B5BC0124B848@exchange-us.scenicsoft.com>
MIME-Version: 1.0
Message-Id: <01103012451903.01515@castel.globaltradedesk.net>
Content-Transfer-Encoding: 8bit
Status: RO
X-Status: Q


Looking forward (technology wise), I tend to agree with:

> > storage/retrieval of well-formed XML is that you can get many benefits of
> > using a DBMS without going through the agonies of data modelling,
> > database design, and performance tuning that RDBMS-based applications
> > traditionally suffer.

The result of a great deal of XML development/operation is that one simply 
ends up with a lot of XML documents.

Document management becomes a big issue. XML documents inevitably land in a 
Document Register for Audit trails.

One could argue that an XML Document Register is the Accounting System of the 
future.

Now of course in big companies, large numbers of techno-boffins will need to 
be around simply because RDBMS provide good solutions. Sophistication of 
the business process means that these databases can always be fine tuned to 
give business information from a different angle.

In smaller companies, Document Registers implemented on dedicated 
hardware costing no more than $100 have to be the way to go. 

I therefore think that the whole idea of an xml database decision tree really 
makes a whole lot of sense going forward, though there are thousands of small 
companies that could use it and some large companies that won't.

 
David

On Tuesday 30 October 2001 01:29, Jeff Lowery wrote:
> > I may be digressing, but an implication of an XML DBMS support for
>
> efficient
>
> > storage/retrieval of well-formed XML is that you can get many benefits of
> > using a DBMS without going through the agonies of data modelling,
> > database design, and performance tuning that RDBMS-based applications
> > traditionally suffer.
>
> Gosh, I would still hope we do data modeling: it's part of data analysis.
> Once you have it at a conceptual level, you still need to physically
> represent it. Although that may be more intuitive (to us) in an XML
> containment hierarchy than it would be in a set of relational tables strung
> together with joins, there's still more than one way to skin a conceptual
> cat, even in XML.
>
> Same goes for performance tuning. If you don't have the right properties
> collocated in the elements, you're going to have a lot unnecessary document
> navigation to do. Again, I don't pretend to imagine that doing it right in
> XML is as hard as doing it right in an RDBMS, but easiest of all is doing
> it wrong in ways multifarious.
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>