Re: What is the logic of storing XML in a Database?

From: David Cressey <cressey73_at_verizon.net>
Date: Wed, 28 Mar 2007 14:21:57 GMT
Message-ID: <9SuOh.5071$J21.3167_at_trndny03>


"Bernard Peek" <bap_at_alpha.shrdlu.com> wrote in message news:slrnf0kn34.esb.bap_at_alpha.shrdlu.com...

> From my experience of replacing legacy formats with XML the main benefits
> are:
>

It depends on what you include as a "legacy format". Some XML evangelizers are calling SQL tables a "legacy format". I don't believe them for an instant, but it's worth making this explicit.

> Data can be validated before it's transmitted. Validation against a schema
> will trap most major errors. It will trap most of the minor errors that
> would normally require action by an expensive and extremely bored human
being.
> Therefore it reduces processing costs and staff turnover.
>

> Errors are rejected by a machine. That usually makes it the sender's
> responsibility to check and correct the data. Making that unambiguous
saves
> a lot of time and endless arguments between business partners.
>
and a DBMS doesn't do this?

> Code to handle XML is standardised and therefore doesn't need to be
> rewritten for each individual application. This makes it more reliable and
> cheaper to develop and maintain.
>

and a DBMS interface language doesn't do this?

> It is difficult to extend CSV systems boyond the simple flat-file system
> with a single record type. Traditionally, at least in the systems I've
> worked with, the solution is to denormalise the data from more than one
> table. Therefore CSV is usually more verbose than XML and can take up much
> more storage space. (The storage space argument isn't one I usually have a
> lot of time for - it's not usually worth bothering with.)
>

CSV is useful (among other things) for unloading an SQL table into a text file,
transporting the text file into a completely different environment, and loading the data into another SQL table. There are better ways, but CSV sometimes works where the better ways are unavailable.

You can deal with normalization problems by simply unloading separate tables to separate CSV files. Your resulting CSV files will typically be smaller than XML files.

> XML data is not generally manually edited, this is a huge advantage.
Fixing
> manually prepared data files soaks up vast amounts of time and effort.
It's
> more likely that XML files will be generated and read by automated systems
> than by someone typing data. That makes XML data much more reliable than
> CSV.
>

You can do the same thing with CSV. I've done it. Received on Wed Mar 28 2007 - 16:21:57 CEST

Original text of this message