Re: sql tables
Date: Thu, 11 Oct 2007 20:18:45 GMT
"Roy Hann" <specially_at_processed.almost.meat> wrote in message
> "David Cressey" <cressey73_at_verizon.net> wrote in message
> > "Roy Hann" <specially_at_processed.almost.meat> wrote in message
> > news:ds2dnQF3Rrfm0pPaRVnyigA_at_pipex.net...
> >> "David Cressey" <cressey73_at_verizon.net> wrote in message
> >> news:2RrPi.10966$br2.10003_at_trndny03...
> >> >
> >> > All of the "major" SQL DBMS products permit storing more than one
> >> > identical
> >> > row in a table. However, they provide several ways the database
> >> > manager
> >> > can
> >> > protect the database from that event. The simplest is to declare a
> >> > primary
> >> > key for the table.
> >> Sadly given that it is now considered "best practice" to blindly and
> >> automatically attach an entirely spurious unique "primary key" value to
> >> every row in a table, that would be entirely futile.
> > Why is is sad? What's wrong with declaring a primary key? Or do mean
> > something else by "attach"?
> I mean precisely that: attach. Construct a tuple that represents your
> proposition, and then *attach* a synthetic value that is chosen precisely
> that it is unique (usually the next sequential number in practice), and
> that your primary key. And that makes me sad.
In that case, I guess you and I are on the same page. I said, and meant, "declare a primary key". Sometimes it's not possible to declare a primary key. More often than not, this means there has been a slip up in the analysis and design.
> Received on Thu Oct 11 2007 - 22:18:45 CEST