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

398
CHAPTER 10 ■ DATABASE TABLES
DNAME
EMPS
LOC
SYS_NC0000400005$
Selecting this column out from the nested table, we’ll see something like this:
ops$tkyte@ORA10G> select SYS_NC0000400005$ from dept_and_emp;
SYS_NC0000400005$
--------------------------------
F60DEEE0FF887BC1E030007F01001321
F60DEEE0FF897BC1E030007F01001321
F60DEEE0FF8A7BC1E030007F01001321
F60DEEE0FF8B7BC1E030007F01001321
The weird-looking column name, SYS_NC0000400005$, is the system-generated key placed
into the DEPT_AND_EMP table. If we dig even deeper, we will find that Oracle has placed a unique
index on this column. Unfortunately, however, it neglected to index the NESTED_TABLE_ID in
EMPS_NT. This column really needs to be indexed, as we are always joining from DEPT_AND_EMP
to EMPS_NT. This is an important thing to remember about nested tables if you use them with
all of the defaults as just done: always index the NESTED_TABLE_ID in the nested tables!
I’ve gotten off track, though, at this point—I was talking about how to treat the nested
table as if it were a real table. The NESTED_TABLE_GET_REFS hint does that for us. We can use the
hint like this:
ops$tkyte@ORA10G> select /*+ nested_table_get_refs */ empno, ename
2 from emps_nt where ename like '%A%';
EMPNO ENAME
---------- ----------
7782 CLARK
7876 ADAMS
7499 ALLEN
7521 WARD
7654 MARTIN
7698 BLAKE
7900 JAMES
7 rows selected.
ops$tkyte@ORA10G> update /*+ nested_table_get_refs */ emps_nt
2 set ename = initcap(ename);
14 rows updated.
ops$tkyte@ORA10G> select /*+ nested_table_get_refs */ empno, ename
2 from emps_nt where ename like '%a%';