OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] SQL instead of XQuery [offtopic]

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

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.


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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS