Re: To foreign key or not to foreign key
- From: Peter Robson <peter.robson@xxxxxxxxx>
- To: fuadar@xxxxxxxxx
- Date: Thu, 16 Dec 2004 17:37:57 +0000
Three issues -
1 - use of FKs. Lex is right - obligatory, to protect data integrity
2 - index each FK? Debateable. Depends on circumstances.
3 - number of FKs in your tables. These do seem to be excessive, which
begs the question over the correctness of the design. Has it been
denomalised in favour of 'performance'? Could be some fundamental
conflicts hidden in here if so.
peter
edinburgh
On Tue, 14 Dec 2004 08:33:52 -0800 (PST), Fuad Arshad <fuadar@xxxxxxxxx> wrote:
> I know this has been discussed here before and i did find a couple of
> jonathan lewis's old posts
>
> The thing is we have a project where the consultants want to ensure about
> 10-15 foreign keys per tables to enforce parent child relationships.
> I've seen locking issues beforer and was wondering if the list could put
> down a some pros and cons as to going or not going with a primary foriegn key
> strategy.
> This is a oltp type system and sub second response is what the enpd product
> requires( isnt that the description of every project these days).
> The consultants want every foreign key indexed. which i think is way too much
> a performance degradation since inserts are going to be major part of the
> application.
>
> --
> //www.freelists.org/webpage/oracle-l
>
--
//www.freelists.org/webpage/oracle-l
Other related posts: