[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: noah_mendelsohn@u..., Michael Kay <mike@s...>
• Date: Tue, 12 Feb 2008 11:11:01 -0600

All true, Noah, but a considerable amount of business is in replacing the
paper-based document systems with relational databases.  True, Michael, the
fit can be uncomfortable, but I seldom see a single 'hotel' object.  I see a
chain of hotels where the information shared or aggregated has a much higher
value than any single instance.   The tradeoff to the relational model is
well worth the fit problems.  Even where there are alternatives (eg, data
cubes), the design and use is not great enough to offset the advantages in
ease, cost and performance of the relational systems.

I realize we can find exceptions to all of these cases, but is there a real
mainstream trend, that is, some change that points to a need to move to
document model storage?  For presentation, there is little doubt that forms
and documents work well for human consumption and production.  I see the
Lotus Notes example.  Question:  did Lotus Notes require a document model or
was it convenient (eg, relational was overkill in this case)?

There are cases where nothing but a document will be accepted, thus, PDF
(final fixed format) for legal documents.  Even then, it seems to be a
matter of practice, not technical requirements.

len


From: noah_mendelsohn@u... [mailto:noah_mendelsohn@u...] 
 
Michael Kay writes:

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

Yes, indeed, but data and document applications are not always separate. 
The example I like to use is of insurance companies.  A list of policy 
holders no doubt fits very well into a relational model, and SQL is great 
for querying and updating it.  For each policy holder there is likely to 
be one or more insurance policy documents, and indeed information like the 
customer ID, policy number, customer's name and address etc. is likely 
shared or linked between the documents and the policy holder list.  Quite 
possibly the policy documents are encoded as some kind of smart template, 
so that a join in a language like XQuery can automatically create the 
policy documents tailored for each customer.  Indeed, there may be logic 
in the template or that XQuery along the lines of:  for any policy in 
excess of $1m, include paragraph 2 on limitations of liability.

The point is that what makes XML so valuable is not just that it can do 
documents, but that it can do these combined document/data applications. 
The xsd:decimal type you use in Schema can be applied to both the amount 
of coverage in the list of policy holders and to the corresponding number 
in the policy document.  You can query for all policy documents in which 
the zip code of the document matches the location of responsibility for 
some the insurance agents in your (data-style) agent list.  It's the 
combination of data and documents in a uniform model that's powerful. 

Of course, there are tradeoffs in all of this.  The JSON community is very 
happy to point out that the mechanisms of XSD and its syntax are 
inconvenient overkill when all you need to pass around are some data-style 
lists of fields, types, values.  They're right about that.  As has been 
eloquently stated on this list, SQL and relational are cleaner (not to say 
having decades of deployment and training investment) when all you need is 
more or less regular data, or things that decompose well into tables. 

I don't have the statistic handy, but many people make the claim that a 
very large fraction of the world's interesting information is stored on 
computers in document style.  Law firms store lists of customers in 
relational (probably), but the contracts, legal decisions, etc. are all 
documents.  In the heydey of relational-only, tables and queries were 
first class, but report writing and document management were sort of an 
add on without a lot of deep architecture and integration.  Now with XML 
we have a system that, however imperfect, can integrate not just the 
managment of data, but the management of the documents created from that 
data, as well as other related documents.  That's a very big deal IMO.

(BTW: Lotus Notes grew up more or less contemporaneously with relational.  
It was one of the first systems to unify data and documents in this style. 
 It's not as open as XML and doesn't aspire to Web scale, and it happens 
to use a flat rather than hierarchical internal model, but otherwise it's 
quite architecturally similar to XML.  Not speaking officially for IBM, I 
believe it has well over 100,000,000 users, depending on how you count.) I 
mention this because Notes was one of the systems that showed that there 
was a real need for something in addition to relational, even as 
relational was growing in popularity.)
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.