[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
RE: [xml-dev] XML vs relational database
- From: "Len Bullard" <cbullard@hiwaay.net>
- To: "'Jim Melton'" <jim.melton@acm.org>, "'Ken North'" <kennorth@sbcglobal.net>
- Date: Thu, 16 Aug 2007 19:26:06 -0500
From: Jim Melton [mailto:jim.melton@acm.org]
Sent: Thursday, August 16, 2007 5:40 P
>Len, as you know, I work for a company founded on and based on SQL,
>and I may be prejudiced.
Of course. I'm a fan of cheap standard tuners for the same reason. Tools
and pay for tools.
>But that doesn't mean that I'm blind.
Not meant or implied. History is what it is because we make our best
choices at a time and the conditions of the time set the where clauses, if I
may be pseudoC-Phil.
>I am a great proponent of helping integrate all sorts of technologies into
>the SQL environment -- as long as it is meaningful and useful to
>those annoyances that pay my salary...customers. That's why I
>participated so actively in the development of ORDBMS (adding object
>capabilities to SQL) in the 1992 - 1999 timeframe, and why I have
>been so passionate about adding the XML type and XQuery integration
>into SQL starting in about 2001 or 2002.
Indeed.
>But you won't find me claiming that SQL does everything.
The books I read basically say if one needs to do fast complex logic or
parse strings, stick with the C#/Java classes. If one needs to manipulate
data fast and reliably, stick with SQL. XML is a case of a syntax being
used as a fuzzy blueprint for a storage representation but essentially, it
is serialization by application objects, or from another view, a pretty-good
if optimized in-memory application db.
Then is comes down to screen flash. Frame rate: the final frontier. :-)
>It's significantly worse at handling arbitrary tree structures, which is
>why we integrated XQuery into SQL/XML instead of trying to train SQL itself
>to do the job.
The need is to understand when to use which for what. XML has an advantage
of being a document given humans are very good at fast loose tree
construction. They manage nesting as a concept pretty well. Good set
design is a different talent and requires some stiffer discipline and
understanding. The payoffs of combining these is that in systems building
where we integrate information from people with different skill sets, we can
keep both busy. Thus, Money. And that's a good thing or so our spouses
tell us.
>Hope this helps,
Always!
len
At 8/16/2007 03:47 PM, Ken North wrote:
> >> We wouldn't have anything. The outcry would have been "SQL does
> all of that
> >> already". If the counter arguments had been one metalevel above
> the current
> >> understanding of the hordes of commenting parties, the political battle
> >> would have been over right there.
>
>Let's distinguish between the storage engine used for an SQL product and
the
>query language itself. Even though the storage engine of an SQL product
might
>handle nested sets, the SQL query language of that era wasn't powerful
enough
>for a reasonable person to argue "SQL does all of that already".
Capabilities
>such as XML schema mapping or using a DTD or schema to validate query
results
>were beyond the scope of the SQL language of that time.
>
>It would surprise me if Jim Melton feels updating the standard from SQL-92
to
>SQL/XML has been a slam dunk.
========================================================================
Jim Melton --- Editor of ISO/IEC 9075-* (SQL) Phone: +1.801.942.0144
Co-Chair, W3C XML Query WG; F&O (etc.) editor Fax : +1.801.942.3345
Oracle Corporation Oracle Email: jim dot melton at oracle dot com
1930 Viscounti Drive Standards email: jim dot melton at acm dot org
Sandy, UT 84093-1063 USA Personal email: jim at melton dot name
========================================================================
= Facts are facts. But any opinions expressed are the opinions =
= only of myself and may or may not reflect the opinions of anybody =
= else with whom I may or may not have discussed the issues at hand. =
========================================================================
_______________________________________________________________________
XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]