On 3/4/13 at 1:49 PM, dix1wjifgt@sneakemail.com (Julian
tempura-at-internode.on.net |pg-gts/Basic|) wrote:
>... having to really think it out is probably a good sign that you
>should stick to a surrogate unless you are really sure. (again I don't
>advocate ON UPDATE CASCADE as a solution should you change your mind)
>
OK this is interesting.
Why not cascade?
Assuming someone makes the dB design as straight forward as
possible, avoids obfuscation of key values (since this mostly
only gets the present and the next developer into trouble, not
the mythical external hacker), and has constraints with cascaded
updates in place to keep it all consistent. Something changes in
the real world, the DBA makes the dB reflect this change and the
cascade ensures everything is still consistent. Where is the
problem with this?
When there is a lot of work involved this needs to be taken into
account, but what is the basis for such a general prohibition on
a modern SQL dB? why not use the feature?
Regards
Gavan Schneider