21.2.3 Storing, Retrieving, and Using Persistent Objects

Thus far, I've only been discussing the definition of the datatypes and the instantiation of objects in the memory of running programs. Fortunately, that's not even half the story! Oracle wouldn't be Oracle if there were no way to store an object in the database.

There are at least two main ways that I could physically store the library catalog as modeled thus far: either as one big table of catalog objects or as a series of smaller tables, one for each subtype. I'll show the former arrangement, which could begin as follows:

CREATE TABLE catalog_items OF catalog_item_t

(CONSTRAINT catalog_items_pk PRIMARY KEY (id));

This statement tells Oracle to build an object table called catalog_items, each row of which will be an object of type catalog_item_t. An object table generally has one column per attribute. Remember, though, that catalog_item_t isn't instantiable, and each row in the table will actually be of a subtype such as a book or serial item. So, somewhere in this table, Oracle will have to come up with a place to store attribute values of each possible subtype. It does this by adding hidden columns to the table, one column per unique subtype attribute. From an object programming point of view, that's pretty cool, because it helps preserve the abstraction of the catalog item, yet provides a way to expose the additional subtype information when needed.

Moving right along, the CONSTRAINT clause designates the id column as the primary key. Yes, object tables can have primary keys too. And, by default, Oracle will also create a system-generated object identifier (OID), as described next.

21.2.3.1 Object identity

In the same way that relational databases include unique identifiers for every row in every table, object-oriented programming systems maintain the unique identity of each object. Generally, OOP systems assign invisible arbitrary numbers to serve as object handles. For any object table, Oracle can base its object identifier on one of two things:

The primary key value

To use this feature, use the clause OBJECT IDENTIFIER IS PRIMARY KEY at the end of the CREATE TABLE statement.

A system-generated value

In this case, Oracle adds another hidden column named SYS_NC_OID$ to the table and populates it with a unique 16-byte RAW value. This is the default behavior.

Not all objects have an object identifier. In particular, objects stored in PL/SQL variables lack a referenceable OID, as do column objects. Oracle takes the view that a column object is dependent on the row's primary key, and should not be independently identified.^[5]

^[5] A contrary view is held by relational industry experts who assert that OIDs should not be used for row identification, and that only column objects should have OIDs. See Hugh Darwen and C. J. Date, "The Third Manifesto," SIGMOD Record, Volume 24 Number 1, March 1995.

Which kind of OID should you use? While primary-key based OIDs typically use less storage than system-generated OIDs, the latter offer unique benefits, as I'll show later. For a more complete discussion of the pros and cons of these two approaches, check out Oracle's document Application Developer's Guide—Object-Relational Features. For now, you should know that a system-generated OID is:

Opaque

Although your programs can use the OID indirectly, you don't typically see its value.

Potentially globally unique across databases

The OID space makes provisions for up to 2128 objects (definitely "many" by the reckoning of the Hottentots).^[6] In theory, these OIDs could allow object navigation across distributed databases without embedding explicit database links.

^[6] The Hottentots had a four-valued counting system: 1, 2, 3, and "many."

Immutable

Immutable in this context means incapable of update. Even after export and import, the OID remains the same, unlike a ROWID. To "change" an OID, you would have to delete and re-create the object.