Michael,
> Is anybody on this thread really rationally suggesting using XML
> instead of SQL? I hope not. It would no longer be an SQL database. Of
> course SQL is the language for committing data to the storage
> mechanism. What the data consists of is another matter.
I'm suggesting there is a good reason for allowing access to a database
in XML in parallel to SQL. I don't care it wouldn't be an SQL database.
Please, read on.
> If some of my data is a paragraph of text of which some of the words
> may be bold, others italics and so on, then I will want to make this
> formatting information part of my data by using XML, RTF or some
> other tagged structure.
>
> If anyone is suggesting that I shouldn't ever do this, but only use
> raw data, then they are nuts.
>
> On the other hand if its being argued that the formatting information
> should be separated from the raw data because you may want to look at
> it in both forms, I can buy that, but the formatting information is
> still data, still stored in the database, maybe just in a separate
> field if you like. If anyone is arguing that the formatting
> information should be stored in some other database, they are also
> nuts.
You shouldn't forget that formatting markup is just one use of XML.
The other one, perhaps the by far the most progressive one, being semantics markup.
To see the difference, let's take the example of an invoice.
If it's represented in a formatting-driven markup, it goes like:
<h1>Invoice no. 1/2001</h1>
<p>
<i>Customer:</i><br />
MathAn Praha, Ltd.<br />
Dlazdena 4<br />
Praha<br />
CZ-11000<br />
Czech Republic<br />
Europe
</p>
<table>
<tr>
<th>Item #</th>
<th>Item description</th>
<th>Quantity</th>
<th>Unit price</th>
<th>Amount</th>
</tr>
<tr>
<td>1</td>
<td>MySQL license</td>
<td>1</td>
<td>200 USD</td>
<td>200 USD</td>
</tr>
<tr>
<td>2</td>
<td>MySQL e-mail support</td>
<td>1 year</td>
<td>170 EURO/year</td>
<td>EURO 170</td>
</tr>
<tr>
<th colspan="4">Total</th>
<td><b>342.45 USD</b></td>
</tr>
</table>
That was HTML, purely presentation.
But machines will also need to understand invoices.
The same invoice could be written as:
<invoice id="invoice:1/2001">
<customer>
<party>
<company-name>MathAn Praha, Ltd.</company-name>
<address type="street" site="HQ">
<address-line><street>Dlazdena</street>
<house-number>4</house-number></address-line>
<address-line><zip-code>CZ-11000</zip-code> <city>Praha</city></address-line>
<address-line><country>Czech Republic</country>,
<continent>Europe</continent></address-line>
</address>
</party>
<customer>
<invoice-lines>
<invoice-line order="1">
<item code="124897435">
<description xml:lang="en">MySQL license</description>
<description xml:lang="cs">Licence MySQL</description>
</item>
<quantity units="piece">1</quantity>
<unit-price units="USD/piece">200</unit-price>
<amount units="USD">200</amount>
</invoice-line>
<invoice-line order="2">
<item code="124897439">
<description xml:lang="en">MySQL basic e-mail support</description>
<description xml:lang="cs">Zakladni e-mailova podpora MySQL</description>
</item>
<quantity units="piece/year">1</quantity>
<unit-price units="EUR/piece*year">170</unit-price>
<amount units="EUR">170</amount>
</invoice-line>
</invoice-lines>
<invoice-total>
<total units="USD">342.654</total>
</invoice-total>
</invoice>
O.k., a real invoice will have a bit more information in it, but that's not important
here.
Now, take the data-oriented markup.
To represent the same information in a relational database,
you'll need several tables: Invoice, InvoiceLine, Item, ItemDescription,
Language(a look-up table), Unit (another look-up table), Party, and Address.
You can parse the document and isolate every XML element value and every XML attribute
and insert them into appropriate columns of the tables.
Probably a glue script to do this is the best choice today.
Likewise, you can take the data stored in the tables of the RDBMS
and run "a few" selects on them and combine the results in such a way
that the XML document for the invoice comes to existence.
Again, a glue script is a clear candidate to do the job.
Now, I'm claiming that in a future that's not at all distant,
the need to do these conversions more and more often
will lead to the following consequences:
1.
The XML <-> RDBMS translation will be understood theoretically and
a formal language to describe the mapping will arise.
2.
DBMS's will be incorporating the translation functionality,
for efficiency and ease-of-use of the XML side of a DBMS will get focus.
The XML interface will call the internal storage API of the DBMS,
not any SQL tier.
3.
With XML becoming more and more popular,
data structures we'll be getting from a DBMS will move from
linear tables to trees. Even internally, the database engines
will start storing data in something else than tables.
4.
The SQL interface will continue to exist and work,
but it will not be the only interface to the data in the database.
Alternative interfaces will rise,
some of which may be based on XML.
Michael, admit that an XML interface to database would give additional flexibility.
Web applications wouldn't need PHP, ASP, JSP, or what the heck other scripting,
that's basically just formatting database output for presentation in a browser -
or at least, not that much of it.
One would be able to say what part of the markup should be deconstructed
and what part should be kept verbatim in the database.
In my example of the invoice,
a good candidate for this disparate handling is the street address:
while I want to store the street address with all the markup for future reference,
I may also want to extract the zipcode alone to look up the location on a map.
With XSLT engines popping up all around,
it's infinetely easier to map data from one structure to another in XML form
than as relational data.
Why not combine the flexibility of XML with the proven storage and concurrency control
mechanisms of a relational database, by adding a XML interface to the existing, SQL
one?
Jan
MichaelMonner wrote:
>
> At 10:37 AM -0600 2/25/01, Cal Evans wrote:
> >Glorious Sunday morning greetings to you Jan,
> >
> >No, XML is a format for 2 different applications, usually 2 totally separate
> >applications, to be able to exchange data. It is not an appropriate choice
> >for storing large amounts of data that will have to be queried. Nor is it an
> >appropriate choice of language for talking to an RDBMS. Outside of the fact
> >that it can be extremely verbose, we already have a perfectly good language
> >for that, SQL. SQL is a language for committing data to a storage mechanism
> >and retrieving the data back. It is superior to XML in those tasks.
>
>
> Mike
>
> ---------------------------------------------------------------------
> Before posting, please check:
> http://www.mysql.com/manual.php (the manual)
> http://lists.mysql.com/ (the list archive)
>
> To request this thread, e-mail <[EMAIL PROTECTED]>
> To unsubscribe, e-mail <[EMAIL PROTECTED]>
> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
