At 09:22 2019-01-26, Ted Roche tedroche@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