(This thread is associated with part 5 of the SqlCredit series published Friday, May 25th.)
Please comment on any aspect of the latest entry in the SqlCredit series: the article, the latest changes to the database code, whatever.
Printable View
(This thread is associated with part 5 of the SqlCredit series published Friday, May 25th.)
Please comment on any aspect of the latest entry in the SqlCredit series: the article, the latest changes to the database code, whatever.
The way it is now (in part 5), I think there are some problems regarding the integrity of data stored in the PrimaryCardHolderID column. I see that you have not created the Account_PrimaryCardholder_FK foreign key, probably to allow entering a 0 for the PrimaryCardHolderID in the _AccountCreate procedure. A better design would be to allow nulls in this column and keep the foreign key. Why? Because now you can delete a card holder (with the CardholderDelete procedure) while it is the primary card holder for an account (as long as there is no card for that holder).
Razvan
My plan is to move this to an associative table mapping a Cardholder to an Account. This will get around all the ugliness that resulted from this weird two-way relationship between Cardholder and Account.