|
TechNotes
Logic in DB
Data Access
SOX
SQL/XML
Restructuring
Trees
Open Source
BizIntel
MySQL
Drivers
ODBC
JDBC
OLE DB
.NET
Podcast
SQL:2003
MS SQL 2005
Webcast
SQL:2003
MS SQL 2005
|
|
1 2 3 4 Next >>
To integrate XML with SQL databases, IBM, Microsoft and Oracle have taken the SQL:2003 path with an XML type and SQL/XML functions. Where does that leave Sybase and open source software such as MySQL, Firebird, Ingres and postgreSQL?
In this article, Michael David suggests a solution for XML integration is to use the hierarchical processing capabilities defined by SQL-92. He explores reasons behind the current SQL native XML integration industry’s slow start, what we should expect from this type of product, what is actually possible, and what hurdles are in the way to accomplish possible advances.
What is the state of SQL native XML integration?
The big three SQL DBMS vendors, IBM, Microsoft, and Oracle, comprise most of the SQL market and are therefore representative of the market. Their SQL native XML integration products rely on proprietary methods, require XML-centric procedural syntax, do not enforce hierarchical processing, and are incompatible with each other. No current SQL native XML integration solution on the market offers a satisfactory solution. This situation has resulted in customers holding off in a waiting mode for a standard, satisfactory solution. Since relational databases are ubiquitous like XML has become, their lack of satisfactory XML support may be retarding Internet growth.
What are the current problems with SQL native XML integration?
XML itself is the cause of many problem areas associated with SQL native XML integration. It was designed as a markup language for text with its semi-structured self defining capability and not for use in database processing. This opens the door for many possible capabilities and situations that do not make good sense for database use. Text processing requires flexible hierarchical structural formations not used in conventional database use. Trying to take advantage of these new found flexibilities and capabilities directly makes a conventional database query language complicated and problematic. Unfortunately, there is a push by the major SQL vendors to support as many XML capabilities as possible, irregardless of the consequences.
With all of its capabilities, it is hard to realize that XML is only a data definition meta language. It leaves the choice of methods for processing data to the application and XML data processing languages that use it. As an example of this, even the basic SAX and DOM parsers can interpret the same XML hierarchical structure differently. This can affect the result. In the same regard, each vendor’s SQL native XML integration solution is different. Having different approaches to the problem requires product-specific use and training. There are too many different solutions to choose from. Compounding this problem is that XML and its uses are still evolving. This makes XML a moving target, with backtracking always a possibility.
|
 Fast, reliable data access for ODBC, JDBC, ADO.NET and XML
|
The common, basic integration technique used for SQL native XML integration is a lowest common denominator approach of flattening the hierarchical data into a relational data form. While this is an easy and obvious approach, it has many downsides for XML support. Unfortunately this flattening technique loses valuable hierarchical semantics when processing the hierarchical data structure.
|
This lost metadata could be used to automatically perform complex multi-leg hierarchical queries non-procedurally. This guarantees a correct XML hierarchical result. Preserving and utilizing these lost capabilities would mean the SQL native XML user would not need to know the data structure being processed. These lost capabilities have not been noticed yet because the SQL/XML industry is still operating with a two-dimensional relational mindset. This has limited XML hierarchical support to a single leg (linear) processing range ignoring the goldmine of freely-available valuable semantic information that exists naturally between hierarchical legs and every node.
1 2 3 4 Next >>
Database Server Watch SQL Summit Home Page Articles
© 2005, Ken North Computing LLC, All rights reserved.
|
|
|
