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

472
CHAPTER 11 ■ INDEXES
ops$tkyte@ORA10GR1> analyze index t_idx validate structure;
Index analyzed.
ops$tkyte@ORA10GR1> select name, lf_rows from index_stats;
NAME
LF_ROWS
------------------------------ ----------
T_IDX 3
The table has four rows, whereas the index only has three. The first three rows, where at
least one of the index key elements was not null, are in the index. The last row with (NULL,
NULL) is not in the index. One of the areas of confusion is when the index is a unique index,
as just shown. Consider the effect of the following three INSERT statements:
ops$tkyte@ORA10GR1> insert into t values ( NULL, NULL );
1 row created.
ops$tkyte@ORA10GR1> insert into t values ( NULL, 1 );
insert into t values ( NULL, 1 )
*
ERROR at line 1:
ORA-00001: unique constraint (OPS$TKYTE.T_IDX) violated
ops$tkyte@ORA10GR1> insert into t values ( 1, NULL );
insert into t values ( 1, NULL )
*
ERROR at line 1:
ORA-00001: unique constraint (OPS$TKYTE.T_IDX) violated
The new (NULL, NULL) row is not considered to be the same as the old row with
(NULL, NULL):
ops$tkyte@ORA10GR1> select x, y, count(*)
2 from t
3 group by x,y
4 having count(*) > 1;
X Y COUNT(*)
---------- ---------- ----------
2
This seems impossible; our unique key isn’t unique if we consider all null entries. The fact
is that, in Oracle, (NULL, NULL) is not the same as (NULL, NULL) when considering uniqueness—the
SQL standard mandates this. (NULL,NULL) and (NULL,NULL) are considered the same
with regard to aggregation, however. The two are unique for comparisons but are the same as
far as the GROUP BY clause is concerned. That is something to consider: each unique constraint
should have at least one NOT NULL column to be truly unique.
The question that comes up with regard to indexes and null values is, “Why isn’t my query
using the index?” The query in question is something like the following: