At 09:22 2019-01-26, Ted Roche <tedroche(a)gmail.com> wrote:
[snip]
>To avoid this kind of refactoring later in the process, my rule has always
>been that every table has a unique, non-data-bearing PK which uniquely
>identifies the record from birth to death. You will never have to deal with
>all the RI code involved in changing primary keys because the data values
>(category or country codes) change, and avoid intricate and bothersome
>code.
Why not? What if someone creates a second restriction row with
the same category, country, and any other factors? Couldn't this
create an integrity nightmare?
In my client billing app, I have a few tables that have a date
range for when each row is valid. This does mean that I have to
handle the lookup into these tables.
[snip]
Sincerely,
Gene Wirchenko