Perhaps there is a place for an XML database for use in storing XML
And more so where the structur nature of the document/record is unknown.
That document can still be indexed by multiple path like statements so a
user can find it easily.
Take the situation where heaps of word documents are being written by many
different authors about a wide range of subjects to many different
adressees. Perhaps those word Documents are best stored in an XML database,
or a "database front end" could be used instead of the normal Hard disk
Only my thoughts.
----- Original Message -----
From: "Eliot, Topher" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Saturday, September 23, 2000 2:46 AM
Subject: Re: XML as Database vs MYSQL etc
> > > Hi,
> > >
> > > I would like to know the Pros and cons of using XML as a
> > database vs MYSQL
> > , Oracle etc!
> > >
> > There is no simple answer to this. However I have taken the liberty of
> > pasting below a couple of relevant passages from "XML Unleashed"
> > <xmlunleashed>
> > Increasingly XML is being used as a data store in its own
> > right. Consider
> > using XML as a primary storage for information when meeting any of the
> > following criteria .criteria.
> > [lb] The information is in a complex form. Some forms of
> > record do not
> > scale well to databases. A doctor's patient record may
> > contain a few office
> > visits or a hundred or more. How should a database be
> > structured to cope
> > with this variation. XML can handle this situation with ease.
> > [lb] The individual fields are large and complex. Again
> > records such as
> > medical records where an office note can be anywhere from a
> > few words to
> > several pages do not store well in databases. In a database
> > each field must
> > be of the same size, so a traditional database can be very wasteful of
> > space.
> I think the author of these points needs to read an introductory database
> textbook. Maybe his knowledge of DBMS is old. Many databases (including
> Oracle) offer a LOB (Large OBject) or BLOB (Binary LOB) or CLOB (Character
> LOB) data type that can hold a field whose size is not predetermined.
> As to not being able to store one or a hundered patient visit records,
> this is a very simple matter of putting the patient visit records into
> another table, indexed by e.g. patient number.
> Neither of these are good reasons to reject using DBMSs in general.
> Maybe some simpler DBMSs don't offer LOBs, but that doesn't make (mis-)
> using XML as a database the right choice.
> > [lb] Speed of searching is not an issue. Database engines
> > are optimized for
> > speed. Although the DOM enables us to carry out any search we
> > want on an XML
> > document it is still a slow process compared with a data base
> > search. At
> > peak periods it is said that the ESPN server carries out
> > 12,000 searches a
> > second! There is no way (at present) that an XML search can cope with
> > numbers like these
> > [lb] Data typing is not important. Everything in XML is
> > stored as a string.
> > Although schemas will allow data descriptions, the
> > information is still
> > stored as a string. Databases on the other hand can store
> > data types in
> > their native format making it easy to pass data to programs
> > that need to
> > manipulate the data. (e.g. an Astronomy program with the
> > co-ordinates of
> > stars). Use a traditional data base to store information of this kind.
> Both valid reasons not to use XML as a database.
> > [lb] The database is small but the need for scalability is
> > important. XML
> > is ideal for small data stores such as will meet the needs of
> > a start up
> > company. Because it is so easy to pass the information to a DBMS if
> > necessary, XML datastores are extremely scaleable.
> An interesting point, but cheap, simple DBMSs like MS Access (shudder)
> would also server for a small company, and would not require
> first learning XML, XSLT, DOM or SAX etc and then re-writing the
> apps to use SQL.
> > </xmlunleashed>
> > <xmlunleashed>
> . . .
> > (d)When to use XML as a data store.
> > Use XML for a data store for all complex documents with
> > structure that does
> > not easily fit into the straightjacket of records and fields. Our file
> > "movies.xml" is a great example of such a file. It allows a
> > flexible number
> > of 'fields' for writers, producers, directors, and actors.
> Again, this mythical "straightjacket" that doesn't allow variable
> numbers of values. True only if you insist on putting everything
> into one table, comparable to putting everything into one element
> All of this completely misses the point of shared access to the DB,
> locking, and transactions, critical to any multi-user environment
> (which of course means it's important to any environment that may
> be multi-user in the future). Most DBMS (but not e.g. MS Access)
> provide this. XML doesn't.