Why XML Over the Relational Model? (fwd)
Jonathan Irving - Sun UK
Jonathan.Irving at UK.Sun.COM
Mon Jan 4 16:04:57 GMT 1999
This got bounced the first time I think - apologies if I'm
duplicating.
cheers
Jonathan
---------- Forwarded message ----------
Date: Mon, 4 Jan 1999 10:00:29 +0000 (GMT)
From: Jonathan Irving - Sun UK <joni at uk.sun.com>
To: Ralf Westphal / BasicPro <RalfW at www.basicworld.com>
Cc: 'Dan Holle' <dan at holle.demon.co.uk>,
'Paul Butkiewicz' <arabbit at earthlink.net>, xml-dev at ic.ac.uk,
xlxp-dev at fsc.fujitsu.com, simonstl at simonstl.com, bckman at ix.netcom.com
Subject: RE: Why XML Over the Relational Model?
Taking this point, Oracle 8i intends to support streaming
XML resulting from queries which contain where clause
XML-specific extensions. I take Matthew's point about cost
and overhead (8i is unlikely to be lightweight by any
definition) but it looks like a resolution to the main
stumbling blocks here.
8i will allow mapping of some or all substructures within
document definitions onto relational tables; the mapping
is done seamlessly (ie when you "put" a document into the
database, you don't need to do complex, mapping-aware
inserts, and when you query a document, the results
returned conform to the appropriate dtd).
Check out the "technical whitepaper" (more appropriate
would be "marketing document") at
http://www.oracle.com/xml/documents/xml_twp/
In all, I agree with all the arguments about attempting to
query large data sets represented in XML being a bit silly,
given the optimisations which have already been done in
most RDBMSs, but this seems to bridge the gap somewhat.
I'm certainly looking forward to playing with it.
Incidentally, although there are SQL extensions planned to
query 8i in an XML way, there's nothing preventing further
use of XQL or XML-QL or any analog on the resulting stream.
cheers
Jonathan
On Mon, 4 Jan 1999, Ralf Westphal / BasicPro wrote:
> Date: Mon, 4 Jan 1999 09:39:00 +0100
> From: Ralf Westphal / BasicPro <RalfW at www.basicworld.com>
> To: 'Dan Holle' <dan at holle.demon.co.uk>,
'Paul Butkiewicz' <arabbit at earthlink.net>, xml-dev at ic.ac.uk,
xlxp-dev at fsc.fujitsu.com, simonstl at simonstl.com, bckman at ix.netcom.com
> Subject: RE: Why XML Over the Relational Model?
>
> Very interesting topic!
>
> But how a about the following twist:
>
> We keep our relational databases for speed etc. and make them accessible
> thru the DOM. That way they´d appear as if they were huge XML files.
>
> It would be a win-win solution:
> -We´d retain all advantages of a dedicated API and a dedicated database
> file format, e.g. indexes.
> -Plus we´d gain a standard API/interface to the data.
>
> Now a user wouldn´t have to care whether data she needs to query resides
> in a true XML file or in a RDBMS. All she needs is a XQL processor
> (take XQL just as an example for a XML query language) and a list of
> filenames.
>
> She then would feed each filename (and her query) to the XQL processor, and
> leave it to the XQL processor to figure out how to get to the data. The
> XQL processor, for example, would look at the filename extension and
> instantiate an appropriate XML parser or DOM object. E.g. for files
> with the extension XML it would instantiate a regular XML parser (like
> MSXML from Microsoft), pass it the XML filename and then execute the
> query using the DOM. For MDB files on the other hand
> (MS Access database files) the XQL processor would not instantiate a
> XML parser (wouldn´t make much sense ;-), but instead a "DOM-component".
>
> A DOM-component implements XML DOM interfaces, so it looks just like a
> XML parser doing the same. So from the outside, one cannot discern if behind
> a DOM-component is a XML file or something else.
>
> Since the DOM-component for MDB files behaves just like a true XML DOM (no,
> even
> better, it _is_ a true XML DOM), the XQL processor again can execute the
> query
> itself.
>
> Benefits:
> -all files and data structures (e.g. file system, list of running processes)
> could be made accessible thru a single API: the DOM
> -a single query language could be used to query (manipulate?) any data
> structure
> -even transparent querying across data structures would be possible (e.g.
> a query could start in a DOM for the file system but could easily continue
> _into_ files pointed to). This kind of querying could be called "universal
> querying".
>
> Possible Objections:
> -Why don´t we just convert all files to XML? We wouldn´t need
> DOM-components.
> Current database file formats are optimized for the purpose. XML is a good
> format for read-mostly/read-only purposes (e.g. in data exchange scenarios);
> but I don´t see megabyte databases stored in XML. The POET ODBMS for example
> converts XML files to its proprietary ODBMS file format before publishing it
> thru a DOM.
> Where XML is a file format ideal for many purposes, but not for all, the XML
> DOM is a truely universal interface to any data, be it the file system or
> a text file. It´s just another kind of API.
>
> -But databases as no XML files so how can we see the thru a DOM?
> The existence of a DOM does not depend on a XML file. A DOM is just a
> hierarchy
> of objects. It´s easy to instantiate a hierarchy of DOM-node objects for
> a hierarchy of directories and files. A DOM-node for a directory, for
> example,
> could return "folder" as its tagName property; and a DOM-node for a file
> could
> have a attribute node called "dateCreated".
> We can see clearly a DOM-component does not need an external XML DTD or XML
> schema.
> Even the concepts of wellformedness and validity loose their values since
> their
> is not data to be parsed. Or the other way round: the data a DOM-component
> is
> always wellformed and valid (because the DOM-component sits on top of a
> specific
> API which ensures the correctness so to speak).
> The hierarchy of node objects in a DOM-component thus does not depend on a
> real DTD or
> real schema, but is predefined by "virtual" schema. The designer of a
> DOM-component
> simply maps a given data structure (e.g. a hierarchy of directories and
> files) to
> a hierarchy of DOM-node objects with certain tag names and attributes and
> values.
>
> -The same XQL query wouldn´t work on different data structures?
> True. But the same holds for queries on RDBMS once they have different table
> structures.
> If you want to query a couple of address databases you´d probably need to
> formulate several SQL queries, since ZIP information in one database is
> stored in a
> column called "ZIP" and in another it´s called "PostalCode".
> On the other hand universal querying would still work for files of the same
> type, e.g.
> all MDB files. If you assume a MDB file is represented by a hierarchy of
> nodes with
> tag names tables/table name=.../row/col name=... you could ask questions
> like "return
> all rows in all tables containing a column named either ´ZIP´ or
> ´PostalCode´ which
> contains the value ´20099´". Fed to a XQL processor with a couple of MDB
> filesnames
> you´d need only this one query to retrieve all addresses with ZIP ´20099´.
>
> -Universal querying could lead to bad performance!
> True. If you´d start a query on a file system DOM-component and let it
> recurse into
> files the performance could go down easily. But then: why not let the user
> decide.
> Maybe it´s more convenient for him to wait than not be able to get at the
> requested
> information at all. At leat he has the possibility to issue a very general
> query and
> not care about file types and file boundaries. DOM-components and XQL
> processors
> are a very powerful concept.
> Also, XQL processors and DOM-components could be made more "intelligent".
> For example,
> before querying a DOM the XQL processor could ask, "do you contain a
> hierarchy of
> row/col nodes at all?" If not, the XQL processor could immediately skip the
> whole
> data structure and continue with the next one.
>
> -But XQL doesn´t allow things like spanning of files etc.
> True, XQL can´t do that - yet. But why not think of extending XQL?
> Today
> folder/file/@name
> results in a list of attribute nodes.
> Today
> folder/file/@name/tables/table
> does not work.
> But tomorrow
> folder/file/@name/tables/table
> could mean, "use the values of the name-attributes as file names, for each
> file name
> instantiate the appropriate DOM-component, and continue the query with the
> rest of
> the query string into the DOM-component".
> Other ways of marking where spanning XML structures/DOMs could be thought
> of.
>
> Hope I didn´t bore you guys too much ;-) But wouldn´t a world with universal
> querying
> capabilities great?
>
> Cheers,
>
> Ralf
>
>
> -----Original Message-----
> From: owner-xml-dev at ic.ac.uk [mailto:owner-xml-dev at ic.ac.uk]On Behalf Of
> Dan Holle
> Sent: Sonntag, 3. Januar 1999 20:25
> To: Paul Butkiewicz; xml-dev at ic.ac.uk; xlxp-dev at fsc.fujitsu.com
> Subject: Re: Why XML Over the Relational Model?
>
>
> >>The primary answer I give this question is flexibility, though there is a
> >>significant cost in efficiency. XML documents can easily hold structures
> >>that make relational databases choke. . . .
> >
> >I would love to see an example of this.
> >
>
>
> Me too, Paul.
>
> Let's not think of XML as a representation for a complex multi-table
> multi-user shared database. DOM, as a database, is like a RAM-resident
> single user IMS/DB. (If you must barf, don't barf on your keyboard.) There
> is a reason why we fled from hierarchical linked databases to relational.
>
> Yes, there are databases you can do in XML that you can't do in relational.
> Just as there are things you can do in assembler language you can't do in
> Java. But if you are trying to do something useful with large, complex
> data, stick with relational.
>
> XML seems a good match for small but flexible structures on web-connected
> clients. David's comments, saying XML is for information exchange and
> relational is for storage/query, rings true...
>
>
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
> To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:majordomo at ic.ac.uk the following
> message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
>
>
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
> To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
>
>
+----------------+-------------------------------------------+
|-- /\ --|-- mailto:Jonathan.Irving at Sun.COM --|
|-- \\ \ --|-- phone:x16112/(+44/0)1276416112 --|
|-- \ \\ / --|-- fax:(+44/0)127625941 /work --|
|-- / \/ / / --+-------------------------------------------+
|-- / / \//\ --|-- http://flag-ir.europe --|
|-- \//\ / / --|-- http://bast.uk --|
|-- / / /\ / --+-------------------------------------------+
|-- / \\ \ --|-- mailto:J at browncat.com --|
|-- \ \\ --+-- http://www.browncat.demon.co.uk --|
|-- \/ --|-- phone:(+44/0)7801866443 /home --|
+----------------+-------------------------------------------+
| ECHELON Fodder | USACIL Chicago Posse Salsa botux |
| | STARLAN BITNET |
+----------------+-------------------------------------------+
+----------------+-------------------------------------------+
|-- /\ --|-- mailto:Jonathan.Irving at Sun.COM --|
|-- \\ \ --|-- phone:x16112/(+44/0)1276416112 --|
|-- \ \\ / --|-- fax:(+44/0)127625941 /work --|
|-- / \/ / / --+-------------------------------------------+
|-- / / \//\ --|-- http://flag-ir.europe --|
|-- \//\ / / --|-- http://bast.uk --|
|-- / / /\ / --+-------------------------------------------+
|-- / \\ \ --|-- mailto:J at browncat.com --|
|-- \ \\ --+-- http://www.browncat.demon.co.uk --|
|-- \/ --|-- phone:(+44/0)7801866443 /home --|
+----------------+-------------------------------------------+
| ECHELON Fodder | munitions Gulf jack codes mania Merv |
+----------------+-------------------------------------------+
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev
mailing list