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

On 2007-03-30, Cimode <cimode_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.

> 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.

>
>> 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. But XML is still useful for many tasks.

-- 
bap_at_shrdlu.com
In search of cognoscenti