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

On 2007-03-30, Cimode <cimode@xxxxxxxxxxx> 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@xxxxxxxxxx
In search of cognoscenti
.

Relevant Pages

  • Re: What is the logic of storing XML in a Database?
    ... I understand that ODBC uses a primitive dialect of SQL to select data ... Why exactly would XML be necessary ... There is a database dump format that exports the database structure and data ...
    (comp.databases.theory)
  • Re: What is the logic of storing XML in a Database?
    ... transfer data and so could replace simple CSV formats. ... If ODBC or similar can handle the communication then it's ... *message* the same way XML or a CSV does. ... But the point seems that direct provider connexion not only ...
    (comp.databases.theory)
  • Re: Accessing many type of DB
    ... specially Excel files, Txt, csv, XML, and may be ... You can write out Recordsets in XML format ... And there is a legacy provider that can connect to ODBC so that ADO ...
    (microsoft.public.data.ado)
  • Re: What is the logic of storing XML in a Database?
    ... transfer data and so could replace simple CSV formats. ... If ODBC or similar can handle the communication then it's ... *message* the same way XML or a CSV does. ... OLE-DB and the current tendancy is for Native Providers. ...
    (comp.databases.theory)
  • Re: What is the logic of storing XML in a Database?
    ... can't do with CSV. ... In what a header does constitute a schema. ... So a schema is the standard structure by which the user sending a file ... in much the same way that XML standards are. ...
    (comp.databases.theory)