In our series on the 11g R2 release of the Oracle RDBMS, AMIS staff discusses various functions, features an facilities that have been added, improved or extended in this latest release. These articles are the fruit of several months of studying this new release and projecting which new features and changes would be the most useful to us in our daily practice. This article looks at apparently relatively minor changes in functionality that may well have a substantial impact on the usability of Abstract Data Types (ADTs) or user defined (object) types.

Using ADTs or user defined types in the Oracle RDBMS is quite often very useful. Much more useful by the way than many developers realize. The integration for example between SQL and PL/SQL can be streamlined using user defined types in conjunction with TABLE and MULTISET or the BULK COLLECT operations. Presenting a service-style interface from PL/SQL packages is also much easier realized using custom type definitions – easier both for the definition of the package’s "service contract", the consumer of the package (at least the Database Adapter used in the SOA Suite) and the developers implementing the service contract. Such a contract in terms of nested types quite close resembles the typicall WebService contract that used nested XML documents.

One less agreeable aspect of types (prior to 11gR2 that is) is their administration. Especially the fact that once a type has been created and has been referenced by other types, it cannot be altered. In order to change a small (or big thing) in a single type, it may be necessary to drop a whole bunch of types that are all somehow related to each other. When the types are all recreated, they can be recreated with the required change inside. Types are much like views or packages: database objects that are owned, have associated privileges and synonyms, and add to the general complexity of database applications.

Note: from the administration perspective, it makes quite a difference whether the types are used only for PL/SQL programs and SQL/PLSQL integration – to define the record structure used for the interaction and to create in memory data structures – or whether the types describe the storage structure for columns or nested tables. In the latter case, changing the type has far more impact than in the previous case – where changing types should not have to have a lot of effect.

In 11gR2, the impact of changing types has been brought to where it really should be: changing a type is allowed even if there are dependencies on that type – as long as those dependencies are not from nested tables/columns. Dependencies from PL/SQL program units or views or other types (that are not used for storage structures) are fine and will allow the change of the type (and even a drop of the type). This ability to modify types without recreating the entire nested structure of inter-dependent types will make use of types in PL/SQL applications much more acceptable to DBAs.

I will show you the scenario that up to 11gR2 would cause the nastiness that has now been resolved in 11gR2:

Read the rest of this entry »