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

On 30 mar, 22:32, Bernard Peek <b..._at_alpha.shrdlu.com> wrote:
> On 2007-03-30, Cimode <cim..._at_hotmail.com> wrote:
>
> >> It can certainly
> >> transfer data and so could replace simple CSV formats. But XML can also
> >> incorporate information about constraints and relationships, I don't believe
> >> ODBC can. If ODBC or similar can handle the communication then it's
> >> probably
> > I am not convinced ODBC or any provider's role is to transport a
> > *message* the same way XML or a CSV does. XML, CSV are file formats
> > while providers ODBC are a middleware that acts as a *translator*
> > between different database querying protocols and querying languages.
>
> Filling the same role as brokers like Biztalk.
I guess you could see it that way. A provider pretty much could also be seen as an *on the fly* system data interface program (a little bit like a common language streamer of data between different systems).

> > When one demands a view from ORACLE on SQL Server, the provider acts
> > as a binding protocol to *represent* the view in SQL Server readable
> > format and vice versa. In such perspective, the schema information is
> > automatically shared as well as the data. In such perspective, the
> > idea is that no additional operation needs to be done to share both
> > header, constraints and data to allow for user interpretation.
> > Besides, providers's code are validated by db editors as a standard
> > while XML and or CSV are usually developped internally. That is done
> > at a much lower cost at all level.
>
> OK, that handles much of the heavy-lifting of direct database-to-database
> transfers, and more efficiently than XML does. But XML isn't restricted to
> those transactions.
Correct. But the point seems that direct provider connexion not only handles *heavy lfting* but it also does *not* have to carry some lifting exclusive to message transport approach using XML. The fact they both have the same end result drives me doubt the real usefulness of using XML as a valid solution to carry data from one system to another system's end user.

> >> preferable to XML. But as I said, I think it needs a more capable language
> >> than the one used on ODBC.
> > ODBC is an underoptimized obsolete provider which has been replaced by
> > OLE-DB and the current tendancy is for Native Providers. It seems
> > difficult for me to compare file formats to middleware.
>
> The job is the same whatever the label. An XML system consists of a data
> source with an XML parser, a data sink with an XML parser, and a transport
> mechanism.

> >> There is a database dump format that exports the database structure and data
> >> in the form of a single SQL command that can create it. If that only
> >> included standards-compliant SQL then it would be a better transfer mediam
> >> than eiher ODBC or XML. But if it contains code that isn't executable in a
> >> different SQL dialect its capabilities are more limited.
> > For view definitions, providers support the translation of most
> > *select* instruction which are sufficient for view definition. The
> > remaining 5% are very specific and proprietary that one easily parse
> > with native providers.
>
> OK
>
>
>
>
>
> > When using *message carrying* approach (sending XML, CSV), one has to:
>
> > --> Run a query against the DB (Eat DB resources)
> > --> Run a XML parser to populate a the query schema and data into an
> > XML file (Eat CPU + Eat Disk)
> > --> Send the file to a receiver (Eat Bandwidth)
> > --> Run XML parser to interpretate data + schema received (Eat CPU +
> > Disk)
> > --> Run parsing into new db of the extracted information (Eat CPU +
> > Disk) on db server
>
> > When using *provider approach*
>
> > --> Receiver send schema info (binding) needed to server (Eats schema
> > bandwidth - neglectable)
> > --> Sender provider parses schema info into server usable SQL
> > instruction (Eat slight CPU for compile )
> > --> Sender sends data + schema (Eat Bandwidth for data in table format
> > - less verbose than XML)
> > --> Receiver presents data.
>
> > Do you still believe that there is a real need for XML except for
> > consuming extra resource?
>
> It's not as efficient in terms of processor power used, and there are better
> methods for a lot of the things it is used for.
>From what I have seen so far, it seems however that it's not just
about processor, but also about disk and time of completion. Not only XML (and to a lesser extent CSV) consumes unecessary CPU, but it also mobilizes unecessary disk space and bandwidth (because of verbose overhead unless compressed prior to transport). The provider based approach allows to consumes only the nessecary bandwidth to get the data to the final end remote user.

<<But XML is still useful for many tasks.>> As far as getting data from a system to another, I really do not believe any interest in using it. It seems its use could and maybe, should be restricted to specific ultra lightweigth punctual carrying of schema or format information such as conveying information about presentation issues (format on documents). That would be consistent with its origin.

Somehow, I think the mistake is to try to use XML *at any cost* while it clearly is *not* adapted and underoptimized for carrying data between systems (to each problem a fitting solution). Could we agree on that and conclude this nice conversation?

> --
> b..._at_shrdlu.com
> In search of cognoscenti
Received on Sat Mar 31 2007 - 12:50:47 CEST