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

On Mar 30, 1:00 pm, Bernard Peek <b..._at_alpha.shrdlu.com> wrote: [Snipped]
> I'm not sure that I would consider ODBC to be perfect.
Who said it was perfect?

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

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

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

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? Received on Fri Mar 30 2007 - 19:25:03 CEST