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

466
CHAPTER 11 ■ INDEXES
ops$tkyte@ORA10G> drop index processed_flag_idx;
Index dropped.
ops$tkyte@ORA10G> create index processed_flag_idx
2 on big_table( case temporary when 'N' then 'N' end );
Index created.
ops$tkyte@ORA10G> analyze index processed_flag_idx
2 validate structure;
Index analyzed.
ops$tkyte@ORA10G> select name, btree_space, lf_rows, height
2 from index_stats;
NAME BTREE_SPACE LF_ROWS HEIGHT
------------------------------ ----------- ---------- ----------
PROCESSED_FLAG_IDX 40012 1779 2
That is quite a difference—the index is some 40KB, not 14.5MB. The height has decreased
as well. If we use this index, we’ll perform one less I/O than we would using the previous taller
index.
Implementing Selective Uniqueness
Another useful technique with function-based indexes is to use them to enforce certain types
of complex constraints. For example, suppose you have a table with versioned information,
such as a projects table. Projects have one of two statuses: either ACTIVE or INACTIVE. You need
to enforce a rule such that “Active projects must have a unique name; inactive projects do
not.” That is, there can only be one active “project X,” but you could have as many inactive
project Xs as you like.
The first response from a developer when they hear this requirement is typically, “We’ll
just run a query to see if there are any active project Xs, and if not, we’ll create ours.” If you
read Chapter 7 (which covers concurrency control and multi-versioning), you understand
that such a simple implementation cannot work in a multiuser environment. If two people
attempt to create a new active project X at the same time, they’ll both succeed. We need to
serialize the creation of project X, but the only way to do that is to lock the entire projects table
(not very concurrent) or use a function-based index and let the database do it for us.
Building on the fact that we can create indexes on functions, that entire null entries are
not made in B*Tree indexes, and that we can create a UNIQUE index, we can easily do the following:
Create unique index active_projects_must_be_unique
On projects ( case when status = 'ACTIVE' then name end );
That would do it. When the status column is ACTIVE, the NAME column will be uniquely
indexed. Any attempt to create active projects with the same name will be detected, and concurrent
access to this table is not compromised at all.