Re: sql table referential integrity

Jay,

If table B is really an "add on" table for table A, then you have a "parent / child" relationship, yes?


In that caxse, you should NOT use an identity column for table B key1, but instead, just define B.key1 as a bigint, and populate it with the corresponding value from table A, hence ensuring the "relationship" (to allow for easy joins, etc.). 


Does that "make sense"?


Mark S. Waterbury


On Thursday, January 30, 2020, 4:40:44 PM EST, Jay Vaughn <jeffersonvaughn@xxxxxxxxx> wrote:

So i have table A (keyed by identity column), and index A (keyed by key1,
key2).

I have table B (keyed by identity column) and index B (keyed by key1, key2
- same defined keys as in index A)

table B is really just an "additional information" table for the rows and
keys defined in table A.

How can I apply some kind of referential integrity over table B to allow
table B keyed rows to be deleted if table A similar keyed rows are
deleted?  Likewise if table A key value changes, table B key values change.

I know I am probably dreaming.  I just don't want to go handle this stuff
programmatically.

tia

Jay