Re: [xml-dev] SQL instead of XQuery [offtopic]

[John Snelson <john.snelson@oracle.com>]

Len, Michael,

Your objections seem to be about collections of homogeneous documents 
being the unit of storage - but an XML database doesn't have to work 
that way. In the hotel example I could quite easily model hotel chain or 
resort information as a different type of document in a collection of 
heterogeneous documents.

To relate things to the relational model, I find it's sometimes useful 
to think of each document in a collection as a row in a table. However 
it can also be useful to think of each document as a table in a 
database. Since a single document is also a valid collection, you can 
also consider an LDAP model of using a single tree to store everything.

In short I don't think it's possible to write off collections of 
documents as a storage model so easily - they clearly offer a superset 
of the functionality in the relational model, and are therefore capable 
of naturally expressing far more complex structures.

John

Len Bullard wrote:
> No argument here, Michael.  A DBA has fits but they have the same fits about
> de-normalizing, and the truth is, storage is cheap now but speed is still at
> a premium.
> 
> My company's owner made a case to me about simplicity of design.  He was
> building a utilities power system application.  He implemented algorithms
> for line length, power loss, ideal transformer loads, etc.  When he showed
> this to his engineers at the power company, they told him this was great
> stuff but that all of the calculations he was doing were standard, and what
> they really needed was a pick list to record what they do on a job.  In
> other words, a not inconsiderable number of applications are just data
> logging applications.  The revelation was that the computer is a very good
> typewriter.
> 
> That said:  the document model works when there is a need to create or
> recreate the context instance of the data log (including the temporal
> context).  Otherwise, messages are messages.   I work with a CAP-capable
> application and will be including some new message types soon, but given all
> of the various contexts the data we log has to fit into, I wouldn't consider
> CAP a good way to organize for storage and reuse nor do I think meta-meta
> schemas such as GJXDM are a good template for table designs.  That is the
> next layer of the problem: schemas for schemas.  Here though, XQuery gets a
> compelling application: contexts wrapping contexts... ad insanitum.
> 
> len
> 
> From: Michael Kay [mailto:mike@saxonica.com] 
> 
>> I think it a huge 
>> conceptual mistake to make document computing the centerpiece 
>> of database design although it is a big win for the GUI.
> 
> It certainly can be a big mistake. I think there are two cases where it
> works well:
> 
> (a) where the documents map well to the business objects that are the
> primary information content of the database. For example a database of
> hotels can work well when implemented as a database holding one document per
> hotel, similarly a database of medicinal drugs. You get issues about where
> to put information that doesn't belong directly with a hotel (e.g.
> information about a hotel chain or about a resort), but if you're clever you
> can present this to viewers (not updaters) as if it's just part of the hotel
> information. (One thing that seems to be lacking from most of today's XML
> databases is this concept of a persistent virtual document or view.)
> 
> (b) where the purpose of the database is to record events and the events are
> captured by documents - for example safety inspection reports or insurance
> claims. In this situation a database of documents is exactly what you need.
> 
> When these conditions don't hold, for example with an HR database, despite
> the fact that XML is very good at handling the flexibility of the data,
> document-centred modelling certainly has its limitations. But then so do
> other modelling techniques. I once asked a data modelling class to model a
> railway timetable - big mistake.
> 
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.
> 
> _______________________________________________________________________
> 
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
> 
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> 


-- 
John Snelson, Oracle Corporation            http://snelson.org.uk/john
Berkeley DB XML:        http://www.oracle.com/database/berkeley-db/xml
XQilla:                                  http://xqilla.sourceforge.net