|
Trends
Logic in DB
Drivers
ODBC
JDBC
OLE DB
.NET
Podcast
SQL:2003
MS SQL 2005
Webcast
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.
|
|
|
