7.9 Implementation Issues

Although only a few readers of this book are likely to be database system implementors, we thought that many of you might be interested in a paragraph or two about some of the challenges that vendors face in building the SQL:1999 structured type features. Undoubtedly, the most complex part of the specification is the routine invocation algorithm; it goes on for several pages of the standard and is extremely dense. However, it is really rather simple and elegant when one pushes through the turgid prose and intricate rules. As a result, it should prove relatively easy to implement and quite stable once done.

By contrast, the concept of subtypes being "specializations" of their supertypes, simply containing a bit more data, seems awfully straightforward. But this may end up being the most difficult aspect of implementing this feature. The problem is caused in part by the very nature of a database management system and in part by the meaning of "subtype."

As you are quite aware, a database system is used for persistent storage of data. The nearly three decades of implementation experience that SQL vendors have accrued in developing their products has largely dealt with tables whose rows were (fairly predictably) all the same length. Of course, there were some minor exceptions, such as very long character string columns, that received special treatment often by means of storing such data in a separate location and then "pointing" to it from the original row value. But, in general,...