[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: SQL instead of XQuery [offtopic]

• From: Len Bullard <len.bullard@u...>
• To: Michael Kay <mike@s...>, 'Ken North' <kennorth@s...>, xml-dev@l...
• Date: Mon, 11 Feb 2008 14:36:37 -0600

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@s...] 

> 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.

• Follow-Ups:
  • Re[2]: SQL instead of XQuery [offtopic]
    • From: Dmitry Turin <dev3os@n...>
  • Re: SQL instead of XQuery [offtopic]
    • From: John Snelson <john.snelson@o...>