• Well, the final paragraph horrfied me. A foreign Key is a CONSTRAINT. It is not a JOIN. JOINS and CONSTRAINTs are vastly different animals.

    The use of Parent Table for referring table in someplces and for referenced table in others is bizarre, and until it is spotted it makes some of the article look like nonsense. It would be better to be consistent in use of this terminology. In fact it would be better still, as someone else said, to use the terms Referring Table and Referenced Table throughout.

    There are many cases where I don't care whether the key is indexed in the referencing table because there is no situation in which the constraint needs to be checked in the direction from the referenced table to the refererring table. As long as the business logic implies that the referenced key is immutable and can't be deleted I have such a case. If I have a natural key that can't be deleted but is mutable I can create an immutable surrogate for foreign key constraints to refer to, so again I have such a case. These cases are pretty common, and in these cases there's no point in indexing the referring columns simply because they are used in a foreign key.

    I like the "Bad Advice" section, but think you are being hopelessly optimistic if you really believe a foreign key constraint will stymie the one power user - he'll disable the constraint to do his delete or insert his nonsense, and if you are really unlucky he will then enable it at peak workload time.

    The script looks useful.

    Tom