WHile designing a Database should one go for composite Primary Keys.
Or what are the Pros and Corns of Composite Primary Keys
ThanxNo, you should only use IDENTITY columns...|||Just kidding...
http://www.datamodel.org/
Define what it takes to uniquely identify a row in a table, no matter how many columns...
And then establish relationships between these objects...
Then you'll have a logical model...
How you physically implement is another story...but start there...|||Come on...I thought that was funny...
..."but what if I need to change the name of a City? Like when New Amsterdam became New York City...IDENTITY would be good there, no?"|||identity? heh, yes, i thought that was funny
and the delivery was excellent
create table constants
( id smallint not null primary key
, name varchar(5) not null
, constant double precision not null
)
insert into constants (name,constant)
values ('pi', 3.141592653589793)
always reference a row by its primary key
which for pi is 1 in the above case, since that was the first constant entered into the table
so whatever id number it gets when you insert that row in your table, just remember the id number and always use it in your sql
the benefit of this is that your sql will not have to change in case pi ever changes its name or value|||http://www.straightdope.com/classics/a3_341.html
A classic I had to look up once more....
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment