TechNotes
Logic in DB
Beyond Java
Data Access
SOX
SQL/XML
Restructuring
Trees
Open Source
BizIntel
MySQL
Drivers
ODBC
JDBC
OLE DB
.NET
Podcast
SQL:2003
MS SQL 2005
XML DBs
XQuery
Webcast
XQuery
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.
|
|
|
