05.11.2015 Views

Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

CHAPTER 12 ■ DATATYPES 555<br />

ROWID/UROWID Types<br />

The last datatypes to discuss are the ROWID <strong>and</strong> UROWID types. A ROWID is the address of a row in<br />

a database. Sufficient information is encoded in the ROWID to locate the row on disk, as well as<br />

identify the object the ROWID points to (the table <strong>and</strong> so on). ROWID’s close relative, UROWID, is a<br />

universal ROWID <strong>and</strong> is used for tables, such as IOTs, <strong>and</strong> tables accessed via gateways to heterogeneous<br />

databases that do not have fixed ROWIDs. The UROWID is a representation of the<br />

primary key value of the row <strong>and</strong>, hence, will vary in size depending on the object it points to.<br />

Every row in every table has either a ROWID or a UROWID associated with it. They are considered<br />

pseudo columns when retrieved from a table, meaning they are not actually stored with<br />

the row, but rather are a derived attribute of the row. A ROWID is generated based on the physical<br />

location of the row; it is not stored with it. A UROWID is generated based on the row’s primary key,<br />

so in a sense it is stored with the row, but not really, as the UROWID does not exist as a discrete<br />

column, but rather as a function of the existing columns.<br />

It used to be that for rows with ROWIDs (the most common “type” of rows in <strong>Oracle</strong>; with<br />

the exception of rows in IOTs, all rows have ROWIDs), the ROWIDs were immutable. When a row<br />

was inserted, it would be associated with a ROWID, an address, <strong>and</strong> that ROWID would be associated<br />

with that row until it was deleted—until it was physically removed from the database.<br />

Over time, this is becoming less true, as there are now operations that may cause a row’s ROWID<br />

to change, for example:<br />

• Updating the partition key of a row in a partitioned table such that the row must move<br />

from one partition to another<br />

• Using the FLASHBACK table comm<strong>and</strong> to restore a database table to a prior point in time<br />

• Performing MOVE operations <strong>and</strong> many partition operations such as splitting or merge<br />

partitions<br />

• Using the ALTER TABLE SHRINK SPACE comm<strong>and</strong> to perform a segment shrink<br />

Now, since ROWIDs can change over time (since they are no longer immutable), it is not<br />

recommended to physically store them as columns in database tables. That is, using a ROWID<br />

as a datatype of a database column is considered a bad practice <strong>and</strong> should be avoided. The<br />

primary key of the row (which should be immutable) should be used instead, <strong>and</strong> referential<br />

integrity can be in place to ensure data integrity is preserved. You cannot do this with the<br />

ROWID types—you cannot create a foreign key from a child table to a parent table by ROWID, <strong>and</strong><br />

you cannot enforce integrity across tables like that. You must use the primary key constraint.<br />

Of what use is the ROWID type, then? It is still useful in applications that allow the end user<br />

to interact with the data—the ROWID, being a physical address of a row, is the fastest way to<br />

access a single row in any table. An application that reads data out of the database <strong>and</strong> presents<br />

it to the end user can use the ROWID upon attempting to update that row. The application<br />

must use the ROWID in combination with other fields or checksums (refer to Chapter 7 for further<br />

information on application locking). In this fashion, you can update the row in question<br />

with the least amount of work (e.g., no index lookup to find the row again) <strong>and</strong> ensure the row<br />

is the same row you read out in the first place by verifying the column values have not<br />

changed. So, a ROWID is useful in applications that employ optimistic locking.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!