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

CHAPTER 10 ■ DATABASE TABLES 355
What is the point of an IOT? You might ask the converse, actually: what is the point of a
heap organized table? Since all tables in a relational database are supposed to have a primary
key anyway, isn’t a heap organized table just a waste of space? We have to make room for both
the table and the index on the primary key of the table when using a heap organized table.
With an IOT, the space overhead of the primary key index is removed, as the index is the data
and the data is the index. The fact is that an index is a complex data structure that requires a
lot of work to manage and maintain, and the maintenance requirements increase as the width
of the row to store increases. A heap, on the other hand, is trivial to manage by comparison.
There are efficiencies in a heap organized table over an IOT. That said, IOTs have some definite
advantages over their heap counterparts. For example, I remember once building an inverted
list index on some textual data (this predated the introduction of interMedia and related technologies).
I had a table full of documents, and I would parse the documents and find words
within them. I had a table that then looked like this:
create table keywords
( word varchar2(50),
position int,
doc_id int,
primary key(word,position,doc_id)
);
Here I had a table that consisted solely of columns of the primary key. I had over 100 percent
overhead; the size of my table and primary key index were comparable (actually, the
primary key index was larger since it physically stored the rowid of the row it pointed to,
whereas a rowid is not stored in the table—it is inferred). I only used this table with a WHERE
clause on the WORD or WORD and POSITION columns. That is, I never used the table—I used only
the index on the table. The table itself was no more than overhead. I wanted to find all documents
containing a given word (or “near” another word, and so on). The heap table was
useless, and it just slowed down the application during maintenance of the KEYWORDS table
and doubled the storage requirements. This is a perfect application for an IOT.
Another implementation that begs for an IOT is a code lookup table. Here you might have
ZIP_CODE to STATE lookup, for example. You can now do away with the heap table and just use
an IOT itself. Anytime you have a table that you access via its primary key exclusively, it is a
candidate for an IOT.
When you want to enforce co-location of data or you want data to be physically stored in
a specific order, the IOT is the structure for you. For users of Sybase and SQL Server, this is
where you would have used a clustered index, but IOTs go one better. A clustered index in
those databases may have up to a 110 percent overhead (similar to the previous KEYWORDS
table example). Here, we have a 0 percent overhead since the data is stored only once. A classic
example of when you might want this physically co-located data would be in a parent/child
relationship. Let’s say the EMP table had a child table containing addresses. You might have a
home address entered into the system when the employee is initially sent an offer letter for a
job, and later he adds his work address. Over time, he moves and changes the home address
to a previous address and adds a new home address. Then he has a school address he added
when he went back for a degree, and so on. That is, the employee has three or four (or more)
detail records, but these details arrive randomly over time. In a normal heap-based table, they
just go “anywhere.” The odds that two or more of the address records would be on the same
database block in the heap table are very near zero. However, when you query an employee’s