Re: Xquery might have some things right
Date: Mon, 8 Mar 2004 21:39:17 -0600
Message-ID: <c2je9a$ne$1_at_news.netins.net>
"Eric Kaun" <ekaun_at_yahoo.com> wrote in message
news:Kt%2c.21999$Ao4.10506_at_newssvr31.news.prodigy.com...
> "Corey Brown" <corey_at_spectrumsoftware.net> wrote in message
> news:V5m2c.66912$Tn.41083_at_bignews5.bellsouth.net...
> >
> > "Mikito Harakiri" <mikharakiri_at_iahu.com> wrote in message
> news:52a2c.37$zW4.263_at_news.oracle.com...
> > > [SNIP]
> > > Sorry, but no, there is no logical redundancy in my approach. Every
> client
> > > queries only the info they want to know. It is extremely rare when
> client
> > > wants the whole database. Usually, client query filters most of the
data
> out
> > > according to some criteria. The other common case is aggregated
report,
> > > where the output is small as well. In both cases extra information is
> > > quickly discarded on server and would never cross the network
boundary.
> > > Whereas in your broadcasting proposal you flood the network with spam
> that
> > > clients rarely care about.
> >
> > Sorry, you're wrong again. I described a publish and subscribe
> mechanism
> > that broadcasts information only to those clients that have
> "subscribed" to
> > that particular publication.
>
> Here's the key word in the entire argument: "publication." This is where
the
> XML / text publishing camp and relational camp diverege greatly. Perhaps
> there are different needs that favor the different camps, but I think the
> relational camp simply subsumes the others because of its ability to
> represent hierarchies simply and cleanly, whereas the converse is not
true.
Definitely a point of disagreement. Simply force XML data to conform to an .xsd and have the xsd require a cardinality no greater than 1 for any element and have no attriburtes (by XML terminology) and you are pretty close to a relational model, right? What's missing? It is much easier for a system modeled on graphs, di-graphs, or trees to pretend to be relational than the other way around, right? For the most part, you can do what you need to do with either model, it is just a matter of how difficult it is to build and maintain. There is at least one XQuery implementation that can work through jdbc, excuting XQuery on an XML view of relational data. There are also SQL implementations on many different database models, often virtually putting data in 1NF in order to execute such queries.
There is a part of this that is a matter of taste, but I hope in the future we can have some actual play-offs between RDBMS's and non-relational counterparts related to the development and maintenance of an actual application. That's a reality TV show I'd like to see.
> What is a "publication"? If that's a simple thing to identify, then fine -
> you're sending a doc identified by some ID or other. What about when a
> client wants only part of a document? What about when they want a small
> collection of documents? What about when they want pieces of various
> documents matching certain criteria?
>
> If their needs are simple, then the simple XML solution might work. When
> needs increase in complexity (i.e. specificity), then the "specification"
> that the clients use to indicate what "publication" they want approaches a
> relational query. And trying to accomplish that via an XML request is
doomed
> to overcomplication, for all the reasons spelled out in Fabian Pascal's
and
> Chris Date's various books.
Don Chamberlin and other relational folks are part of XQuery development. They took XPath and added to it (for handling multiple documents or large documents) and then also, for no reason other than their relational heritage, they lopped off navigational functions found in XPath, forcing more complex query statements for some of the navigation. But when doing Xquery you are not doing only relational queries -- you are doing something much more like PICK queries, but without the ease of reading them that you get with PICK (bz extending the vocabulary hides code from users). I suspect that "doomed" is too strong a word. Stay tuned.
> Again, there are applications where the simplistic need is the only
need...
> but they're subsumed by relations.
>
> > In your solution, every client interested in a particular
> > piece of information would have to query the server, essentially at
> the same
> > time, to retrieve it. Unless you can think of some way of throttling
> your clients,
> > I don't see how your solution would ever scale.
>
> You're assuming a remote DB access that works the same way as existing
JDBC
> and ODBC libraries: creating a connection, sending various queries,
closing
> the connection. The query could easily work like an HTTP request, for
which
> there are many varied "scalable" solutions. Or using Jabber protocols. Or
an
> asynchronous one. There are many options. The point is this: when client
> needs vary widely, trying to "push" to each of them involves a lot of
extra
> complexity on the server side, plus you have to reinvent a
pseudo-relational
> query mechanism anyway. Another wheel!
But the SQL wheel is beyond squeaky -- it needs to be replaced. From "XQuery from the Experts" 2004 Chamberlin et al, p385 "either the SQL model itself must be extended to deal with the nonrelational aspects of order and heterogeneity...or the SQL model will eventually be subsumed under the XML and XQuery model" I'm not saying that SQL is dead yet (just like COBOL isn't dead) but if anyone has a choice of databases and/or data access languages might think twice before jumping into SQL if you don't have to.
XQuery is not salvation by any means, but it does appear to be contending
with many of SQL's weaknesses. I'm happy to stick with PICK (e.g. UniData
or UniVerse databases from IBM, jBASE, Revelation, D3, UniVision, Reality)
for the time being given that it is proven technology (with a rather nice,
if never standardized query language).
--dawn
Received on Tue Mar 09 2004 - 04:39:17 CET