At 3/3/2003 04:39 PM, you wrote:

>A reason not to place dependencies on these columns is that, if a
>particular user were to be removed from the Users table, relationships
>would be broken everywhere. This type of "user-stamping" usually has to be
>designed to survive changes to the parent table.

Yes, that's a good point. Although my apps typically do not delete users,
you never know what a maintenance programmer is going to think a good idea is.

>You *can* do this with referential integrity; but I guess you have to
>decide whether you want the extra cost of two additional referential
>integrity checks on every row in
>your database.

That's what I couldn't swallow, and made me post the question here.

>If users are allowed to enter their own IDs, then the preferred solution
>would be to use the triggers for your checks. Even better would be to have
>some means to do the stamping automatically in the triggers and disallow
>users from subsequently tampering with those columns where they are visible
>in applications.

Yes, exactly. There is a username/password that is updateable by the user,
but the User_ID is a generator-supplied PK, so no problems there.

thanks for confirming my suspicions,

Bob M..