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

"JOG" <jog_at_cs.nott.ac.uk> wrote in message news:1175112245.717262.275350_at_d57g2000hsg.googlegroups.com...
> I'm sure there are many people who have been through the same
> experience as myself using xml as a transport format:
>
> 1) Observe the popularity of XML and the supporting libraries in the
> language you are working in.
> 2) Implement a transport layer using XML to parse messages/data etc.
> 3) Realise that your server/application is now over ten times slower
> than it was before.
> 4) Remove XML and replace with something far simpler, far less verbose
> and vitally far /quicker to parse/.
> 5) Curse XML for wasting your bloody time and never let it darken your
> door again.
>
>

There are really two discussions going on in parallel in this thread.

One is about using XML for data transfer outside of a DBMS. I'm saying "DBMS" rather than "Database" intentionally here. A DBMS can move data across a network link, and even pass it to an inter-DBMS gateway.

The other, the one actually asked by the OP, is about declaring columns of type XML in tables.

I use CSV for data tranfer between one DBMS and another, when I don't have a workable gateway between the two DBMSes. It works just fine for me, and I see no reason to add the complexity of XML.

I see no reason to store XML database inside an SQL table. Perhaps if you wanted to keep an accurate record of the incriminating evidence.

Also, in your precis above, you implicitly refer to the "thundering herd" argument. I buy the thundering herd argument as a reason for conforming, at times. I don't buy it as the path to excellence. Excellent solutions are almost always beyond the reach of the thundering herd.

The trick is to figure out when good enough is good enough, and when it's not. Received on Thu Mar 29 2007 - 11:01:05 CEST