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

On Mar 28, 12:04 pm, "Cimode" <cim..._at_hotmail.com> wrote:
> On Mar 28, 4:45 pm, "Daniel" <danielapar..._at_gmail.com> wrote:> On Mar 28, >
> What is the interest of using an XML file instead of directly sharing
> a view
> with the destination user...

That would suggest at a minimum of sharing DBMS connections with the customer, and likely a broker or exchange as well, which is a pretty strong form of coupling. Consider one particular ecommerce situation: there is you, and another company that you're not communicating with directly, and a third party broker that is mediating the exchange. Messages containing trade details are flowing between you and the other company, through the broker, managed electronically, until agreement is achieved. Every day you could be dealing with different customers, with whom you haven't had a prior business relationship. Experience suggests that in today's world, loose coupling works better. I don't mind qualifying that by suggesting that in a future world, there might be superior solutions.
>
> > As an example, an XML Schema may declare that an element named
> > dayCountFraction is of type DayCountFraction.
>
> > <xsd:element name="dayCountFraction" type="DayCountFraction">
>
> > The type DayCountFraction may restrict the values that the field
> > dayCountFraction can take to a specific list, e.g. "ACT/ACT",
> > "30/360", "30/365".
>
> Ah OK...What process does it use to do the filtering...Does not the
> navigation consume extra resources?
>
Some piece of middleware or some application at the endpoints parses the message, and validates the message against the rules in the schema document. Sure, it consumes extra resources. But in many cases, that's not a problem. Sometimes it is, if the volumes are very high.
>
>
> *Well formedness*. What does it add to validate for instance to a
> constraint definition in a db?

DB constraint definitions don't apply to messages because messages aren't structured like DB relations. Even if you believe that the DB constraints guarantee the correctness of the source data, they don't guarantee the correctness of the mapping rules that populate the messages. The messages have to be validated independently.
>
> > Not a company, rather an entire industry.
>
> So you are saying that some industry implement it and some not.
>

Communication between companies is becoming increasingly important, and communication requires a common vocabulary. Industry specific vocabularies tend to be driven by industry consortiums of the leading companies in an industry. While inter-company and ecommerce considerations tend to drive the standardization process, the standards tend to become adopted in new initiatives within companies, simply because they have to use something for internal messaging, and adopting an industry standard can prove to be simpler than making up something themselves, or evolving their legacy formats.

> > I have a CSV file of trades (with many duplicate
> > fields per row) that occupies 9,884KB, and an XML file generated from
> > that CSV file, in a standard industry format, that occupies
> > 34,012KB.
>
> But Bernard Peek suggests the opposite...
>
:-)

In my experience, in finance, XML files tend to be 5-10 times larger than their CSV or other legacy counterparts. Whether that's a problem or not depends on volumes. In certain very high volume businesses, like exchange traded equity, the larger sizes can be a big problem. But also note that when these files are sent over a wire, they compress a lot, the middleware generally supports compression.

Regards,
Daniel Parker Received on Wed Mar 28 2007 - 20:13:25 CEST