At 09:22 2019-01-26, Ted Roche <[email protected]> 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 _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/93ea9c5e198e85a53f2a9cfd7ba03e99@mtlp000085 ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
