On Thu, Sep 4, 2008 at 6:11 PM, Steve Miller <Steve_Miller@...> wrote:

> I am working on an application that has object data mapped to tables.
> The mapping was done many years ago, before the likes of Hibernate came
> along. It basically maps a class to a table. Object properties with
> multiple values get their own tables. There are other interesting
> mappings, but that's the overall concept.
>
> We have a guy that has been doing research on an alternate approach.
> He's storing the object data in an XML string. The XML string is stored
> in the only field of a table. The table is the only one in the system.
> He's reporting huge performance increases with this approach.
>
> Have any of you heard of anything like this? What do you see are the
> pros and cons of such an approach?

Hi Steve,

If your friend is storing everythign in a single table, then how is he
going to handle the relationships between you data? Are you going to
store the whole relationship as a single xml tree? That is really bad
design.

The only time I advise you do this is when you are working with
structured content for websites, or some sort of content or document
management system.
If you are working with a object-oriented data models, then do a
mapping. Don't store the whole thing as xml. Besides, XML is a very
heavy format. It adds a lot of extra junk data. For instance, let's
say you have the following xml representation of a CD:

<cd>
<artist>Artist1</artist>
<genre>Pop Music</genre>
<track num="1">
<title>title1</title>
</track>
.........
</cd>

If you have a look at the data, the only important data in there are:
Artist1, Pop Music, 1, title1. All the rest is junk. And if you add
all the tags you will see that the total number of characters your
tags generate are much higher than the data you really need. You are
storing a lot of junk data.

So, be careful when you work with XML in relational databases.

Others may have other views with regards to this, but that is my opinion.

Fidel.