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

rekharaghuram
from rekharaghuram More from this publisher
05.11.2015 Views

CHAPTER 10 ■ DATABASE TABLES 401 "DNAME" VARCHAR2(14), "LOC" VARCHAR2(13), "EMPS" "OPS$TKYTE"."EMP_TAB_TYPE" , PRIMARY KEY ("DEPTNO") USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 TABLESPACE "USERS" ENABLE ) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING TABLESPACE "USERS" NESTED TABLE "EMPS" STORE AS "EMPS_NT" (PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 LOGGING TABLESPACE "USERS" ) RETURN AS VALUE The only new thing here so far is the RETURN AS VALUE. It is used to describe how the nested table is returned to a client application. By default, Oracle will return the nested table by value to the client; the actual data will be transmitted with each row. This can also be set to RETURN AS LOCATOR, meaning the client will get a pointer to the data, not the data itself. If—and only if—the client dereferences this pointer will the data be transmitted to it. So, if you believe the client will typically not look at the rows of a nested table for each parent row, you can return a locator instead of the values, saving on the network round-trips. For example, if you have a client application that displays the lists of departments and when the user doubleclicks a department it shows the employee information, you may consider using the locator. This is because the details are usually not looked at—that is the exception, not the rule. So, what else can we do with the nested table? First, the NESTED_TABLE_ID column must be indexed. Since we always access the nested table from the parent to the child, we really need that index. We can index that column using CREATE INDEX, but a better solution is to use an IOT to store the nested table. The nested table is another perfect example of what an IOT is excellent for. It will physically store the child rows co-located by NESTED_TABLE_ID (so retrieving the table is done with less physical I/O). It will remove the need for the redundant index on the RAW(16) column. Going one step further, since the NESTED_TABLE_ID will be the leading column in the IOT’s primary key, we should also incorporate index key compression to suppress the redundant NESTED_TABLE_IDs that would be there otherwise. In addition, we can incorporate our UNIQUE and NOT NULL constraint on the EMPNO column into the CREATE TABLE command. Therefore, if we take the preceding CREATE TABLE and modify it slightly, as follows: ops$tkyte@ORA10G> CREATE TABLE "OPS$TKYTE"."DEPT_AND_EMP" 2 ("DEPTNO" NUMBER(2, 0), 3 "DNAME" VARCHAR2(14), 4 "LOC" VARCHAR2(13), 5 "EMPS" "EMP_TAB_TYPE") 6 PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 LOGGING 7 STORAGE(INITIAL 131072 NEXT 131072 8 MINEXTENTS 1 MAXEXTENTS 4096 9 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 10 BUFFER_POOL DEFAULT) 11 TABLESPACE "USERS" 12 NESTED TABLE "EMPS" 13 STORE AS "EMPS_NT" 14 ( (empno NOT NULL, unique (empno), primary key(nested_table_id,empno))

402 CHAPTER 10 ■ DATABASE TABLES 15 organization index compress 1 ) 16 RETURN AS VALUE 17 / Table created. we now get the following set of objects. Instead of having a conventional table EMP_NT, we have an IOT EMPS_NT as signified by the index structure overlaid on the table in Figure 10-12. Figure 10-12. Nested table implemented as an IOT Where the EMPS_NT is an IOT using compression, it should take less storage than the original default nested table and it has the index we badly need. Nested Tables Wrap-Up I do not use nested tables as a permanent storage mechanism myself, for the following reasons: • The unnecessary storage overhead of the RAW(16) columns that are added. Both the parent and child table will have this extra column. The parent table will have an extra 16-byte RAW for each nested table column it has. Since the parent table typically already has a primary key (DEPTNO in my examples), it makes sense to use this key in the child tables, not a system-generated key. • The unnecessary overhead of the additional unique constraint on the parent table, when it typically already has a unique constraint. • The nested table is not easily used by itself, without using unsupported constructs (NESTED_TABLE_GET_REFS). It can be un-nested for queries, but not mass updates. I have yet to find a table in real life that isn’t queried “by itself.”

402<br />

CHAPTER 10 ■ DATABASE TABLES<br />

15 organization index compress 1 )<br />

16 RETURN AS VALUE<br />

17 /<br />

Table created.<br />

we now get the following set of objects. Instead of having a conventional table EMP_NT, we have<br />

an IOT EMPS_NT as signified by the index structure overlaid on the table in Figure 10-12.<br />

Figure 10-12. Nested table implemented as an IOT<br />

Where the EMPS_NT is an IOT using compression, it should take less storage than the original<br />

default nested table <strong>and</strong> it has the index we badly need.<br />

Nested Tables Wrap-Up<br />

I do not use nested tables as a permanent storage mechanism myself, for the following reasons:<br />

• The unnecessary storage overhead of the RAW(16) columns that are added. Both the<br />

parent <strong>and</strong> child table will have this extra column. The parent table will have an extra<br />

16-byte RAW for each nested table column it has. Since the parent table typically<br />

already has a primary key (DEPTNO in my examples), it makes sense to use this key in<br />

the child tables, not a system-generated key.<br />

• The unnecessary overhead of the additional unique constraint on the parent table,<br />

when it typically already has a unique constraint.<br />

• The nested table is not easily used by itself, without using unsupported constructs<br />

(NESTED_TABLE_GET_REFS). It can be un-nested for queries, but not mass updates. I have<br />

yet to find a table in real life that isn’t queried “by itself.”

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

Saved successfully!

Ooh no, something went wrong!