[
Lists Home |
Date Index |
Thread Index
]
Michael Kay wrote:
>>If we are querying over a bunch of back-end relational
>>databases, why is
>>XQuery better than some flavor of SQL? At least the type system
>>mismatch could be manageable.
>>
>>
>
>There are many people who seem to think that 99% of the world's data is held
>in relational databases. They are badly wrong.
>
>I had some involvement with an internet banking application a few years ago.
>When the customer logged on, all the relevant customer and account
>information was assembled from various back-end systems into an XML document
>which was then used as session data for the duration of the session. If I
>remember rightly, there were about six back-end systems involved, and only
>one was relational. The main operational transaction system was accessed by
>sending an application-level CICS transaction to a mainframe. Many of the
>other databases were ad-hoc, for example information about recent
>interactions with the telephone call centre was in Lotus Notes.
>
>
at least i now understand why i can't change my address at the bank
reliably, and they have multiple copies that don't agree and none of
them are right <sigh />
>The beauty of using XML for this kind of information integration is that it
>allows the resulting data to have a much richer structure. This makes it
>much easier to combine the structured data with the relatively unstructured,
>and handle the semantic conflicts that occur: for example if two databases
>record different phone numbers for a customer, you just capture both. That
>is very much harder to do if the result has to be in relational form.
>
>
i think that's just plain wrong, but i take your earlier note about not
everything being in rdbms as more significant
>Decomposing relational queries to address multiple relational data sources
>is by now a well-understood problem, but it only works if each data source
>can be modelled in terms of a relational view. If the actual data is the
>archive of an email mailing list, modelling it as a collection of XML
>documents is probably going to be much easier. I see no reason why the same
>query decomposition techniques shouldn't work with XQuery as with SQL, but
>the technique will be far more powerful simply because XML is a richer
>model.
>
>
<permathread temptation="resisted for now" />
>As for the type system mismatch, everything maps to text, and XML is
>essentially text, so what's the problem? The fact that XML is text-based is
>another benefit.
>
>
>
so what we really have is the one of the old principles of logic a=>b is
always true if a is false
a is "everything is stored in relational databases"
the real benefit you've pointed out is putting multiple, othorgonal,
inconsistent data sources together and being able to query them with one
language - now you have my attention.
but i still like xslt for dosument transformations :) i spend my days
processing electronic orders in all sorts of forms -> xsl -> database or
printing labels (yes there's a whole industry in that) sku data -> xml
-> customer specific transform -> printer or printing invoices (same
architecture)
stuff comes in or out of the database to xml and is processed somewhere
by xslt.
etc
but with things like emails now an important part of the production
process, we are looking at archiving techniques that can be used to
marry the emails back to the databases and this might be a good way forward.
rick
>Michael Kay
>http://www.saxonica.com/
>
>
>-----------------------------------------------------------------
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>
>To subscribe or unsubscribe from this list use the subscription
>manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
>
begin:vcard
fn:Rick Marshall
n:Marshall;Rick
email;internet:rjm@zenucom.com
tel;cell:+61 411 287 530
x-mozilla-html:TRUE
version:2.1
end:vcard
|
