http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:8135488196597 I would not encourage the use of either nested tables or varrays to persist (store on disk) data.
For starters, I want to know who has phone number 123-456-7890
if you "hide" phone number as a nested table/varray of a person - it becomes very cumbersome to query. Phone numbers stand alone as an entity in most cases, they should not be hidden.
I wrote in Expert one on one Oracle (in summary):
<quote>
Nested Tables Wrap-up
I do not use nested tables as a permanent storage mechanism myself, and this is for the following reasons:
o The 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 would make sense to use this in the child tables, not a system generated key
o The overhead of the unique constraint on the parent table, when it already typically has a unique constraint.
o The nested table is not easily used by itself, without using unsupported constructs (NESTED_TABLE_GET_REFS). It can be unnested for queries but not mass updates.
I do use nested tables heavily as a programming construct and in views. This is where I believe they are in their element and in Chapter XX Using Object Relational Features we see how to exploit them in this fashion. As a storage mechanism I would much prefer creating the parent/child tables myself. After creating the parent/child tables ¿ we can in fact create a view that makes it appear as if we had a real nested table. That is, we can achieve all of the advantages of the nested table construct without incurring the overhead. Again in Chapter XX Using Object Relational Features we¿ll take a detailed look at how to accomplish this.
If you do use them as a storage mechanism, be sure to make the nested table an ORGANIZATION INDEX table to avoid the overhead of an index on the NESTED_TABLE_ID and the nested table itself. See the section above on IOTS for advice on setting them up with overflow segments and other options. If you do not use an IOT, make sure then to create an index on the NESTED_TABLE_ID column in the nested table to avoid full scanning it to find the child rows.
</quote>
So, my suggestion:
good old fashioned relational tables.