>No, I think this doesn´t quite solve the problem. I should define the
>surrogate key as PRIMARY and my original key as CANDIDATE, and the problem
>would keep popping up. (Defining the original key as REGULAR just ignores
>the problem.)
it solved the problem in the sense that each record that is added has a
unique key
you have to check for duplicate "data" keys in the insert trigger etc.
>
>I'm not sure about this either; in the many-to-many link I would need to
>use, instead of KEY_A+KEY_B, SURROGATE_A+SURROGATE_B; the problem with
>compound indexes would remain. Anyway, you would need to define KEY_A+KEY_B
>as CANDIDATE, and the original problem is still with us.
no as you would add a 3rd surrogate key for the N-N connection table and
have the other keys as foreign keys in this table..
>I have been showing my example code to many FoxPro programmers, and they
>all called it a serious problem. When I worked with old fashioned things
>like COBOL, if I deleted a primary key, it stayed deleted! (It didn't´t
show
>up in READs, it caused no problems in WRITEs, and so on.)
this is what you pay for having the option to RECALL deleted records
btw you can also recycle Deleted keys (i.e. re-use the deleted record)
Arnon
Précédent
Répondre
Voir le fil de ce thread
Voir le fil de ce thread à partir de ce message seulement
Voir tous les messages de ce thread
Voir tous les messages de ce thread à partir de ce message seulement