Re: Identity Column Benefits

From: Alan <alanshein_at_erols.spambuster.com>
Date: 2000/06/20
Message-ID: <8ioavg$am2$1_at_bob.news.rcn.net>#1/1


The design used is really the "right" (better) way to do it. It is relationally correct, and allows for easy changes or additions to the attributes ("Subject", "Category", etc.) without the need for programmer intervention.

Alex wrote in message <8PL35.11$SE3.2482_at_typhoon2.ba-dsg.net>...
>Hello,
> I've just taken over the management of a project and I'm a bit
 concerned
>about one of the earlier design decisions that was made. We have
>quotations, stories, poems, etc... stored in a table called "Content".
>There are several tables hanging off of this main table such as
>"ContentSubject", "Subject", "ContentCategory", "Category". The primary
 key
>on the Content table is a field of type varchar that is a unique index.
>There is nothing special about this field's data, as it is only used as a
>"handle" for the data. The DB we are using is SQL 7.0. My concern is that
>I'm used to using the identity property for columns such as this, and I had
>never given much thought to doing it any other way. The biggest benefit I
>see is that the field is automatically incremented by the DB, rather than
>having the developers do it through code. I'm not really looking to switch
>to ID properties at this point, but I wanted to know if anyone out there
 had
>any compelling reasons to switch perhaps based on performance of ID columns
>when executing queries or joings, or simliar performance concerns with a
>field of type varchar. Please let me know.
>
>Thanks,
>
>Alex
>
>
Received on Tue Jun 20 2000 - 00:00:00 CEST

Original text of this message