Charlotte Foust
charlotte.foust at gmail.com
Fri May 27 11:52:16 CDT 2011
I've argued with experts about IKs like social security numbers. Their arguments always seem to boil down to, "Well, they don't USUALLY change, so that's OK." I prefer to violate strict normalization and include an IK that CAN be changed and an autonumber that can't. Then when the IK must be changed (i.e., wrong SSN), the connections among tables aren't lost. Charlotte Foust On Fri, May 27, 2011 at 9:09 AM, Arthur Fuller <fuller.artful at gmail.com> wrote: > With all due respect, I suggest that you read some Codd and Date on this > topic.As for the complexities involved in use of IKs, it is brain-dead easy. > > > But that said, I am not a big fan of IKs. Like most of us on this forum, I > tend to favour AutoNumber out of force of habit rather than rational > analysis. I have read numerous things by Joe Celko and Chis Date which > refute the use of AutoNumber|Idnentity Keys, and I accept them halfway. I > don't give a fork from which a given tire was hatched, unless and until > several of these instances have caused highway fatalities. Therefore, I need > build this (batch) into the design, so that I can report to all owners of > said tires a warning that there are potential issues. > > This is going to be extremely problematic to solve with the AutoNumber > scenario. An intelligent key could make the query dramatically simpler. > > That's all I'm saying. I typically use AutoNumbers in almost every app I > write, but the more crucial and life-threatening the app, the more likely I > shall use IKs. > > A. > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com >