LOL, maybe you just weren’t wrong…?

When one uses an object-relational/extensible DBMS’s extensibility, one is indeed still banging data into rows somewhere. That’s why Oracle and DB2 put text into BLOBs/CLOBs, for example.

But one can index however one likes, no? (Again, consider the text example.)

I guess what I’m missing is this — where does DB2’s datatype extensibility fail? What unacceptable overhead does it impose in the case of XML?

I’ve gotten the message that I used to overrate datatype extensibility like Oracle’s, DB2’s, and Informix/Illustra’s. What I haven’t figured out yet, however, is WHY I was wrong.

Thanks,

CAM

Answers to your questions above…

The reason that IBM did not use DB2’s general datatype extensibility framework is because we decided not to simply “extend” our existing infrastructure to support XML like many vendors did. Instead, we spent 5 years developing XML-specific infrastructure from the ground up.

IBM essentially has traditional relational infrastructure and XML infrastructure in the physical layer. It then has a unified runtime execution layer above this which, for the most part, “hides” the physical storage considerations. This unified execution runtime layer provides the data manipulation and retrieval languages. (I say “for the most part” because there are certain physical storage settings that you want to be able to configure). All the management tooling, including backup/restore, utilities, and high availability are supported for XML data.

DB2’s parser handles both SQL (and its extensions for XML) as well as native XQuery, and translates them into a common set of instructions. Of course, this is different to some relational vendors who translate XQuery into SQL.