Notes in-line
--
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
The educated person is not the person
who can answer the questions, but the
person who can question the answers -- T. Schick Jr
One-day tutorials:
http://www.jlcomp.demon.co.uk/tutorial.html
____Belgium__November (EOUG event - "Troubleshooting")
____UK_______December (UKOUG conference - "CBO")
Three-day seminar:
see http://www.jlcomp.demon.co.uk/seminar.html
____UK___November
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
"mcstock" <mcstock_at_enquery.com> wrote in message
news:gLmdnS-8d_Dc1QWiRVn-gg_at_comcast.com...
> yes, the PK value is stored in the 'parent' table, the FK value is
stored in
> each referencing row in the 'child' table
>
It mya be true, but this does not constitute an argument for
making PK's short and arbitrary.
> this is one reason why PK's should be short and arbitrary (and not
> updatable)-- it is usually bad design to have a varchar2(60) as a PK
(and
> hence as an FK)
I agree only up to thethe point that a 'real' primary key which
happens to be 60 characters is a little unlikely, and the appearance
of varchar2(60) as the primary key would make me check if the
designer had done something silly like space padding and concatenating
several fields to produce a single column key.
> it is usually best to use a number column and automatically assign
the PK
> from a SEQUENCE object via a TRIGGER.
>
It is rarely a good idea to do this - it introducs an extra column on
top of
the real key; it introduces an extra index on top of the real primar
key index,
it causes queries that should be adressed only at the child table end
up
joining to the parent table on the menaningl number to identify the
relevant child
rows, and it results in code that does extra database calls.
> When mnemonic PKs cannot be avoided, it is best to keep them as
short as
> possible -- i usually use VARCHAR2(12)
>
Received on Mon Oct 27 2003 - 02:04:25 CST
