XML vs. SQL

devinkouts@earthlink.net devinkouts@earthlink.net
Wed, 10 Jan 2001 15:03:51 -0500


Roger, there's quite a big difference between XML and SQL. For instance:

>What's about storing data in a SQL data base?

What I think you meant here is a "relational" data base that can be
accessed with SQL. The intent of XML is to store data in a flat file,
humanly readable, easily accessbible form. Methods for accessing an XML
data "store" are quite robust and evolving all the time, to include a
proposal from Microsoft for "XQL" - an SQL equivalent designed to
manipulate XML data stores.


>- Lots of data bases are freeware or even open source products...

But to use them you must learn to use a database. A heavy requirement
for the average cave surveyor. XML on the other hand needs little more
than an editor like Windows Notepad and you can build a great store for
your data.

>- SQL is as well as XML an industry standard.
No argument there, but again we have apples and oranges. SQL is for
manipulating stored data. XML is for storing data.

>- Lots of ODBC / JDBC drivers are available and ready for production.

Agree, but these are of little interest to the cave surveyor who wants
to store his data in a standard format that can be shared around the
world. ODBC and JDBC is used by the software developer to get to data.

>- SQL servers are ready for network computing.

Agreed, but this is no advantage over XML, which itself is well designed
for network computing, given the ability to format XML data with style
sheets and then embed that data in html pages (even format network
messages as XML data stores).

>- SQL is fast.

Agreed, fast for retrieving data. But we're just talking about storing
data at this point.

>- And now the most important: SQL is flexible and easy to use. Even on
the text console only a few lines of code are enough to do complex  data
base queries.

This is also true, but this statement illustrates the appropriate place
for SQL, in the hands of someone who needs to do queries against an
existing data store, i.e. a developer.

>In XML you either produce a large and complicated text file with a huge
amount of additional data or you have to fiddle around with several
files.

In all fairness XML can be wordy, but that is by design. One of the
fundamental requirements of XML is that it be humanly readable. That
requirement results in the use of human language as delimeters and
identifiers. This adds bulk to the data store, but frankly bulk is not
such an issue these days (not when I can by a 20GB hard drive for $100
US). As for complexity, I would disagree. XML is anything but complex,
in fact I find it to be very logically organized, in a hierarchical
structure similar to the directory structure you use on you PC or Unix
workstation. The use of multiple XML files, with cross links, is no
different from multiple tables in a data base. One distinct advantage
XML offers over relational stores is the limitless hierarchical nature
of an XML store. Relational stores on the other hand are limited to
basically three levels of hierarchy, 1 - data base, 2 - table, and 3 -
record.

I'm not trying to shoot holes in SQL Roger, I'm just trying to
illustrate that SQL is not appropriate to this segment of what we're
trying to do. XML on the other hand allows us to build the "simple" data
stores that we need for "exchanging" data.

Devin Kouts