Re: What is the logic of storing XML in a Database?
Date: Wed, 28 Mar 2007 14:21:57 GMT
Message-ID: <9SuOh.5071$J21.3167_at_trndny03>
> 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.)
>
> 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