What is the logic of storing XML in a Database?

On Mar 26, 11:15 pm, "Karen Hill" wrote:
> X-No-Archive:yes
>
> I see people putting XML documents in databases. Why do they do this,
> what is the logic behind it? Why not just put the data into tables?
> Why are the standards committees going along with this (XML SQL/
> MED)? Why don't people just use tables to store the data thusly:
>
> CREATE TABLE FOO_CUSTOMER
> (
> name VARCHAR
> address VARCHAR
> key INT
> );
>
> why are they doing this:
>
> CREATE TABLE BAD_XML_CUSTOMER
> (
> customer_data XML
>
> );
XML is a hybrid reeminiscence of hierarchical/navigational approach
for storing data. There is no inherent objective logic to it. In
other words, don't search coherence in incoherence.
 >> Stay informed about: What is the logic of storing XML in a Database? 

> On 2007-03-26, Karen Hill wrote:
>
> I see people putting XML documents in databases. Why do they do this,
> what is the logic behind it? Why not just put the data into tables?
> Why are the standards committees going along with this (XML SQL/
> MED)? Why don't people just use tables to store the data thusly:

Laziness. Lack of knowledge of data fundamentals. Miseducation. Having
a manager who is a constant victim to the latest marketing fad. Take
your pick.
 >> Stay informed about: What is the logic of storing XML in a Database? 

On 03/27/07 11:11, Bob Badour wrote:
> Karen Hill wrote:
>> X-No-Archive:yes
>>
>> I see people putting XML documents in databases. Why do they do this,
[...]
> The short answer is "stupidity and ignorance".

A potent combination, that one. :^)

There is presumably something about human nature that makes us keep
coming back to hierarchical structures for data. And ignoring history.

I would say that if you can treat the XML document as an atomic value,
then storing it in a database attribute could be appropriate. But, yes,
your example with all the customer details nested inside an XML document
in a column in a table: weird and icky. :^)
--
Chris
 >> Stay informed about: What is the logic of storing XML in a Database? 

On 2007-03-26, Karen Hill wrote:
> X-No-Archive:yes
>
> I see people putting XML documents in databases. Why do they do this,
> what is the logic behind it? Why not just put the data into tables?
> Why are the standards committees going along with this (XML SQL/
> MED)? Why don't people just use tables to store the data thusly:

The answer is that it enables people to store data in a badly structured
format without having to justify that to their DBA.


--
bap RemoveThis @shrdlu.com
In search of cognoscenti
 >> Stay informed about: What is the logic of storing XML in a Database? 

On Mar 26, 6:15 pm, "Karen Hill" wrote:
> X-No-Archive:yes
>
> I see people putting XML documents in databases. Why do they do this,
> what is the logic behind it? Why not just put the data into tables?
> Why are the standards committees going along with this (XML SQL/
> MED)? Why don't people just use tables to store the data.

The question can't be answered without knowing more about the problem
that is to be solved.

Standardized XML transport formats are commonly used for representing
messages. Consider a problem space where messages are sent from a
front office system to a back office system, and middleware needs to
keep a repository of messages to support auditing and playback. In
that case it would make perfect sense to strip out any fields required
for querying, and store them plus the message. Storing all the fields
relationally would not meet any business objective, and it might not
be possible to reliably reproduce the original message from the
relational representation.

Regards,
Daniel Parker
 >> Stay informed about: What is the logic of storing XML in a Database? 

On Mar 27, 8:10 am, "Daniel" wrote:
> Standardized XML transport formats are commonly used for representing
> messages.

You'll get no sympathy for these ideas here. What are "transport" and
"messages"? Those concepts are below the abstraction level database
operates. In database world you just query what you need to know; you
don't sift through all the spam that friendly systems pushed to you.

If "transport" and "messages" are merely implementation details of
some distributed database application, then it can be argued that a
design that is not burdened by XML would be much more effective.
 >> Stay informed about: What is the logic of storing XML in a Database? 

On 2007-03-27, JOG wrote:
>> On 2007-03-26, Karen Hill wrote:
>>
>> I see people putting XML documents in databases. Why do they do this,
>> what is the logic behind it? Why not just put the data into tables?
>> Why are the standards committees going along with this (XML SQL/
>> MED)? Why don't people just use tables to store the data thusly:
>
> Laziness. Lack of knowledge of data fundamentals. Miseducation. Having
> a manager who is a constant victim to the latest marketing fad. Take
> your pick.

I have to add that XML has its place, but as a blob in a database is not it.



--
bap RemoveThis @shrdlu.com
In search of cognoscenti
 >> Stay informed about: What is the logic of storing XML in a Database? 

On 2007-03-27, Daniel wrote:
> On Mar 26, 6:15 pm, "Karen Hill" wrote:
>> X-No-Archive:yes
>>
>> I see people putting XML documents in databases. Why do they do this,
>> what is the logic behind it? Why not just put the data into tables?
>> Why are the standards committees going along with this (XML SQL/
>> MED)? Why don't people just use tables to store the data.
>
> The question can't be answered without knowing more about the problem
> that is to be solved.
>
> Standardized XML transport formats are commonly used for representing
> messages. Consider a problem space where messages are sent from a
> front office system to a back office system, and middleware needs to
> keep a repository of messages to support auditing and playback. In
> that case it would make perfect sense to strip out any fields required
> for querying, and store them plus the message. Storing all the fields
> relationally would not meet any business objective, and it might not
> be possible to reliably reproduce the original message from the
> relational representation.

I've just posted another message saying that XML has its place. It's
invaluable in messaging systems because a message can be validated before
being sent. That won't trap every error but it it can a lot. The really neat
thing is that the data gets rejected by a machine, so you don't get people
phoning and asking you to correct the data they sent you.




--
bap.DeleteThis@shrdlu.com
In search of cognoscenti
 >> Stay informed about: What is the logic of storing XML in a Database? 

On Mar 27, 1:34 pm, "Aloha Kakuikanu"
wrote:
> On Mar 27, 8:10 am, "Daniel" wrote:
>
> > Standardized XML transport formats are commonly used for representing
> > messages.
>
> If "transport" and "messages" are merely implementation details of
> some distributed database application,

But of course they're not, they have nothing really to do with
distributed database application, nor is it desirable that they
should. Consequently they have nothing really to do with dbms theory.

> then it can be argued that a
> design that is not burdened by XML would be much more effective.

The current best practice seems to be for messages to be encoded in a
text format, be self contained, and be validatable against some schema
representation. The less the endpoints are coupled, the better. XML
appears to be the most widely embraced format that fullfils these
requirements, and widespread adoption has its own benefits, much as in
the case of SQL. There's also some interest in other formats, such as
JSON. But of course, this is outside the scope of database theory,
and it's understandable that you have no interest in the subject.

Best regards,
Daniel
 >> Stay informed about: What is the logic of storing XML in a Database? 

On Mar 27, 3:35 pm, "David Cressey" wrote:
> "Daniel" wrote in message
>
>
>
> > On Mar 27, 1:34 pm, "Aloha Kakuikanu"
> > wrote:
> > > If "transport" and "messages" are merely implementation details of
> > > some distributed database application,
>
> > But of course they're not, they have nothing really to do with
> > distributed database application, nor is it desirable that they
> > should. Consequently they have nothing really to do with dbms theory.
>
> There are three things you can do with data: process it, store it, and
> transport it.
> These three are all interrelated.
>
But they're not governed by the same considerations. The fact that
data storage benefits from normalization, for example, doesn't mean
that transport formats benefit from normalization.

Regards,
Daniel Parker
 >> Stay informed about: What is the logic of storing XML in a Database? 

On Mar 27, 11:45 am, Bob Badour wrote:
> David Cressey wrote:
>
> > There are three things you can do with data: process it, store it, and
> > transport it. These three are all interrelated.
>
> That seems so limiting like having an emotional vocabulary of happy, sad
> and angry.

XML makes me sad and angry.


Marshall
 >> Stay informed about: What is the logic of storing XML in a Database? 

On Mar 27, 4:15 pm, "Marshall" wrote:
> On Mar 27, 11:45 am, Bob Badour wrote:
>
> > David Cressey wrote:
>
> > > There are three things you can do with data: process it, store it, and
> > > transport it. These three are all interrelated.
>
> > That seems so limiting like having an emotional vocabulary of happy, sad
> > and angry.
>
> XML makes me sad and angry.
>
Well, there are different aspects to XML.

There really are people who think that XML databases are a good thing
because they allow you to put data into storage without having to
model the data, because "everybody" knows that modelling data is too
hard. Of course, there's that little matter of getting data out
again, but they have hopes that following conventions for positioning
some key tags will lead to a good result. These are the same people
who used to believe that storing name/value pairs in database tables
was a good thing. I can understand that that would make you
unhappy.

There's also the niggling detail that the standard XML query language
can return different results depending on whether or not it's a schema-
aware implementation, and I can understand that that would make you
unhappy.

But why would you be unhappy about XML as a transport format? It's
mostly an improvement over what we had before - CSV files, binary
formats, etc.

Regards,
Daniel Parker
 >> Stay informed about: What is the logic of storing XML in a Database? 

On Mar 27, 1:39 pm, "Daniel" wrote:
> But why would you be unhappy about XML as a transport format? It's
> mostly an improvement over what we had before - CSV files, binary
> formats, etc.

So you have a string a characters and want to represent its structure?
It is not a secret that XML sucks in this respect as well:

http://www-128.ibm.com/developerworks/xml/library/x-sbxml.html

It is an unfortunate historical artifact that today's parser engines
are so user-unfriendly that programmers prefer to sing and dance
though all the horrors of XML rather than to approach the problem from
language perspective.
 >> Stay informed about: What is the logic of storing XML in a Database?