Re: What is the logic of storing XML in a Database?
Date: 28 Mar 2007 11:13:25 -0700
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.
Daniel Parker Received on Wed Mar 28 2007 - 20:13:25 CEST