For awhile I tried to avoid using IDENTITY columns in the name of
theoretical "best practices." However, it seemed to cause quite a few
problems in regards to data storage (whatever ended up as the primary key
was invariably larger and more cumbersome than an integer field) and
terribly difficult to update (e.g. foreign key constraints needed to be
dropped before updating data in the primary key field and recreated
afterwards). In addition, the abstraction of the PRIMARY KEY from the data
works towards normalizing (not "normalizing" in the sense of relational data
but in the lay sense) database design, layout and implementation. On the
other hand, avoiding IDENTITY columns didn't fix any practical problems.
For these reasons, I've reversed my position and include IDENTITY columns on
most tables that require a primary key.
Benjamin S. Rogers
Web Developer, c4.net
voice: (508) 240-0051
fax: (508) 240-0057
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
