-----Original Message-----
From: Gary McNeel, Jr. [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 11, 2000 3:33 PM
To: [EMAIL PROTECTED]
Subject: RE: RE: What are you using instead of IDENTITY?
Man, am I glad I am not a DBA and let myself get constrained by hypothetical
arguments. We have old databases here that did NOT use an IDENTITY field.
Man, what a mess that has been.
Example: For years the KEY to a manila file folder was the date and the
number of applications done that day. This was the offices' procedure, told
people what was in the file folder. So you had 99062301 for 1999 (year),
06(month), 23(day), 01(number sequence for that day). This was the primary
key and was stored in a numeric (Access) field. They then used this for
foreign keys. Guess what happened? Y2Kish issue. Numeric fields truncated
the leading zeros and was that a mess. 00010101 became 10101, etc.
This site is being completely redesigned (there were many more issues here,
it was quasi-relational, lot of duplicate data, etc.)
I have used IDENTITY fields for many years and have encountered NO problems.
The problems I have encountered are when a User uses the IDENTITY as part of
the data for the record, for instance John Doe is record 6. Now, when you
export and append this to another table, boom, the IDENTITY is hosed. There
are ways around this, but you get the idea.
I don't know, from my perspective you just can't beat IDENTITY fields (but
maybe I am looking down from the edge of a penny (dime?)). ;)
OK, back to the Moody Blues and some CF coding.
-Gary McNeel
> -----Original Message-----
> From: Benjamin S. Rogers [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 11, 2000 12:55 PM
> To: [EMAIL PROTECTED]
> Subject: RE: RE: What are you using instead of IDENTITY?
>
>
> 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/[email protected]/
> 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.
----------------------------------------------------------------------------
--
Archives: http://www.mail-archive.com/[email protected]/
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.
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/[email protected]/
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.
