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

From: Cimode <cimode_at_hotmail.com>
Date: 29 Mar 2007 07:52:35 -0700
Message-ID: <1175179955.104759.220740_at_n76g2000hsh.googlegroups.com>


On Mar 29, 10:01 am, "David Cressey" <cresse..._at_verizon.net> wrote:
> "JOG" <j..._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.
Agreed. But I am afraid that discussing the use of XML or CSV quickly becomes a sterile debate. I did it in the purpose to trigger some questions about XML.

View network sharing seems however to be the only fundamentally optimal solution. The receiver of some EDI information is simply a remote user from the perspective of the dbms. In such perspective, defining views the receiver can interpretate and openning the right ports (with an adequate TCPIP topology) is much simpler than adding an entire applicative layer to handle the *carrying* of some encapsulated message. In other words, I strongly doubt of the real need for sending a message (be it CSV or XML or anything) as opposed to simply sharing a view. Received on Thu Mar 29 2007 - 16:52:35 CEST

Original text of this message