Optimal SQL/XML
Home Up



Fast, reliable data access for ODBC, JDBC, ADO.NET and XML
Business Intelligence with R&R ReportWorks
Got SOX compliance?
Movielink Logo 88x31
IBM eserver xSeries 306m 8849 - P4 3.4 GHz
iTunes Logo 88x31-1


A Platform-Neutral Solution to Native XML Integration with SQL (part 2)

Logic in DB



MS SQL 2005


MS SQL 2005



<<Previous 1 2 3 4 Next>>

What should we expect and not expect from SQLs 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 SQLs 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 XMLs 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 SQLs sound mathematical foundation.


Keeping within these boundaries, SQL should support as many XML capabilities as possible when they are useful and do not lessen SQLs 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 

Visit GridSummit.com (Grid Computing Knowledge Portal)


2005, Ken North Computing LLC, All rights reserved.


Travel Money
Movielink Generic 120X90 Animated