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
|
|
<<Previous
1 2
3 4
Next>>
What should we expect and not expect
from SQL’s support of XML?
To the SQL user, native XML support means SQL is XML-enabled, supporting
native XML input and output. The rest of the XML features supported are left
up to the SQL vendor. How all of these capabilities are implemented is also
left up to the vendor. This XML support should be performed without changing
SQL’s look and feel. Any additions to SQL should remain non-procedural and
SQL centric. Changing SQL to be more XML-centric is a slippery slope, slowly
changing SQL into a XML-centric language. SQL centric XML support should be
consistent throughout SQL operation. XML should be working for SQL and not
the other way around. Heavy duty procedural XML processing should be left to
dedicated XML processors.
As discussed previously, some features of XML are not appropriate for a
language like SQL. Even XML-centric processors have realized there are too
many capabilities to support and do not try to support all XML capabilities.
So why should we expect SQL to support them all? In addition, SQL is used
heavily for mission-critical operations in production applications, so the
XML capabilities it supports directly should produce consistent, predictable
results. The use of XML’s semi-structured capability to produce
unconventional and unpredictable hierarchical structures when manipulated
directly by SQL has not been proven. One thing is certain; it can weaken
SQL’s sound mathematical foundation.
 
|
Keeping within these boundaries, SQL should support as many XML capabilities
as possible when they are useful and do not lessen SQL’s strengths. XML support
should be transparent as possible. Wildly varying hierarchical structures, while
required for marked-up text, need to be separated from database hierarchical
processing to limit its direct SQL use. Functions can be used in SQL database
processing to process marked-up text without requiring direct XML integration.
|
Is there an optimal SQL XML solution
available?
It turns out that with the introduction of the Left Outer Join in the
ANSI SQL-92 standard, the capability to perform full hierarchical processing
inherently in ANSI SQL became possible. Performed in SQL, this hierarchical
processing is a valid subset of relational processing. This allows many
outstanding capabilities for the seamless and transparent SQL integration of
native XML not achieved so far in the SQL industry.
First and most importantly, this solution serves as the common bond
between relational and XML hierarchical processing. Instead of using the
lowest common denominator of relational data by flattening XML data as a
common bond, it uses hierarchical processing as the common denominator by
naturally raising SQL processing to a full hierarchical processing level.
This also has the significant advantage of basing this solution on the solid
principled proven hierarchical technology. This is a considerable
improvement over betting the bank on a new data format language like XML and
its processing capabilities that are not necessarily based on a solid,
principled technology foundation. This new high level hierarchical bonding
also acts as a buffer from changes to XML because hierarchical principles,
and not XML itself, form the common bond.
Ed: Because this solution to XML integration does not
require SQL:2003 conformance, it's available with any SQL DBMS that
implements the earlier 1992 or 1999 standards.
<<Previous 1
2 3
4
Next>>
Database Server Watch
SQL Summit Home
Page Articles
© 2005, Ken North Computing LLC, All rights
reserved.
|
|
|
