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

CHAPTER 10 ■ DATABASE TABLES 419
We looked at cluster objects, of which Oracle has three kinds: index, hash, and sorted
hash. The goals of the cluster are twofold:
• To give us the ability to store data from many tables together on the same database
block(s).
• To give us the ability to force like data to be stored physically “together” based on some
cluster key. In this fashion all of the data for department 10 (from many tables) may be
stored together.
These features allow us to access related data very quickly, with minimal physical I/O. We
observed the main differences between index clusters and hash clusters, and discussed when
each would (and would not) be appropriate.
Next, we moved on to cover nested tables. We reviewed the syntax, semantics, and usage
of nested tables. We saw how they are in a fact a system-generated and -maintained parent/
child pair of tables, and we discovered how Oracle physically does this for us. We looked at
using different table types for nested tables, which by default use a heap-based table. We
found that there will probably never be a reason not to use an IOT instead of a heap table for
nested tables.
Then we looked into the ins and outs of temporary tables, including how to create them,
where they get their storage from, and the fact that they introduce no concurrency-related
issues at runtime. We explored the differences between session-level and transaction-level
temporary tables, and we discussed the appropriate method for using temporary tables in an
Oracle database.
This chapter finished with a look at the inner workings of object tables. As with nested
tables, we discovered there is a lot going on under the covers with object tables in Oracle. We
discussed how object views on top of relational tables can give us the functionality of an
object table, while at the same time offering easy access to the underlying relational data.