85 million row table, key was coupon code and "used/unused" flag ....
updates were done in batches as the coupons were processed. We did NOT
have performance problems. We didn't have to worry about the FK index
as it was a standalone table.

No gotchas under the conditions we used it.=20

I see scattered implementations of IOTs here and again, all I hear are
good things about it (other than the "index" is in the "data"
tablespace.... running and ducking now!)

Daniel Fink <Daniel.Fink_at_Sun.COM> wrote:
> We are looking to implement IOTs for a couple of intersection> entities in a 10g db. I would like to hear from those brave> enough to actually use IOTs what is the good, the bad and the> ugly.=20
>=20
> example:
>=20
> Employee (heap table)> Project (heap table)
>=20
> There is a many-to-many relationship between the tables (1> employee can be on many projects and 1 project can have many> employees).
>=20
> The emp_project table is the intersection entity containing> emp_id and project_id as the only columns. There are FK> constraints on each of the columns. The combination of emp_id> and project_id is unique.
>=20
> This situation *sounds* like the right one for an IOT,> otherwise we would have 1 table and 2 indexes (1 on each> column).
>=20
> My main concerns are:> 1) Integrity/performance> 2) Locking behavior (do I need to adhere to the traditional> "index all foreign keys" rule to prevent excessive locking?)> 3) Any especially nasty gotchas
>=20
> Thanks,> Daniel> ----------------------------------------------------------------> Please see the official ORACLE-L FAQ: http://www.orafaq.com> ----------------------------------------------------------------> To unsubscribe send email to: oracle-l-request_at_freelists.org> put 'unsubscribe' in the subject line.> --> Archives are at http://www.freelists.org/archives/oracle-l/> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html> -----------------------------------------------------------------