Re: XML Database Decision Tree?
?= <3549BAFD79A7D411A1CF00508B62B5BC0124B848@e...> MIME-Version: 1.0 Message-Id: <01103012451903.01515@c...> 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>
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format