Hi all,
I am wandering about the pros and cons of creating a separate serial field
for a primary key when I already have a single unique field. This existing
unique field will have to be a character of fixed length (VARCHAR(12))
because although it's a numeric value there will be leading zeroes.
Title: RE: [GENERAL] primary key and existing unique fields
Since you already have the unique field I see no point in adding a sequence to the table, unless of course the sequence of the data inserts is of importance at some point.
Duane
-Original Message-
From: Sally Sally [mailto
Sally Sally wrote:
Hi all,
I am wandering about the pros and cons of creating a separate serial
field for a primary key when I already have a single unique field. This
existing unique field will have to be a character of fixed length
(VARCHAR(12)) because although it's a numeric value there will
TECTED]>
CC: [EMAIL PROTECTED]
Subject: Re: [GENERAL] primary key and existing unique fields
Date: Tue, 26 Oct 2004 09:48:50 -0700
Sally Sally wrote:
Hi all,
I am wandering about the pros and cons of creating a separate serial field
for a primary key when I already have a single unique field.
Sally Sally wrote:
Can you please elaborate on the point you just made as to why the
primary key should not relate to the data (even for a case when there is
an existing unique field that can be used to identify the record)
Here is a good article on the topic:
http://www.devx.com/ibm/Article/207
Joshua D. Drake wrote:
Sally Sally wrote:
Can you please elaborate on the point you just made as to why the
primary key should not relate to the data (even for a case when there
is an existing unique field that can be used to identify the record)
Here is a good article on the topic:
http://www.d
Here is a good article on the topic:
http://www.devx.com/ibm/Article/20702
The surrogate key isn't solving the underlying logical inconsistency
problem. It is being used as a work-around to cover one up. I suspect
the author of being a MySQL user.
Actually he is a software project consultant for
Joshua D. Drake wrote:
Here is a good article on the topic:
http://www.devx.com/ibm/Article/20702
The surrogate key isn't solving the underlying logical inconsistency
problem. It is being used as a work-around to cover one up. I suspect
the author of being a MySQL user.
Actually he is a softwar
On Tue, 26 Oct 2004 16:24:44 +, Sally Sally <[EMAIL PROTECTED]> wrote:
> Hi all,
> I am wandering about the pros and cons of creating a separate serial field
> for a primary key when I already have a single unique field. This existing
> unique field will have to be a character of fixed length (
Title: RE: [GENERAL] primary key and existing unique fields
Look at the database design in terms of data retrieval. If I add a sequence number as my primary key, when I get ready to retrieve that record "directly" how do I know what that sequence number is. For instance, my emplo
> That article makes me want to vomit uncontrollably! ;-)
>
> "Business data might also simply be bad -- glitches in the Social
> Security Administration's system may lead to different persons having
> the same Social Security Number. A surrogate key helps to isolate the
> system from such pro
On Tue, 2004-10-26 at 17:26 -0400, Mike Mascari wrote:
>
>
> Apparently gamma functions and string theory have little to do with
> understanding the relational model of data.
>
>
m.. string theory. :-)
--
/***
* Robby Russell | Owner.Developer.Geek
On Tue, 26 Oct 2004 17:05:27 -0700, Robby Russell <[EMAIL PROTECTED]> wrote:
> On Tue, 2004-10-26 at 17:26 -0400, Mike Mascari wrote:
> >
> >
> > Apparently gamma functions and string theory have little to do with
> > understanding the relational model of data.
> >
> >
>
> m.. string theory.
On Tue, 2004-10-26 at 22:03 -0500, Kevin Barnard wrote:
> On Tue, 26 Oct 2004 17:05:27 -0700, Robby Russell <[EMAIL PROTECTED]> wrote:
> > On Tue, 2004-10-26 at 17:26 -0400, Mike Mascari wrote:
> > >
> > >
> > > Apparently gamma functions and string theory have little to do with
> > > understandin
-Original Message-
From: Robby Russell [mailto:[EMAIL PROTECTED]
Sent: Tue 10/26/2004 9:08 PM
To: Kevin Barnard
Cc: [EMAIL PROTECTED]
Subject:Re: [GENERAL] primary key and existing unique fields
On Tue, 2004-10-26 at 22:03 -0500, Kevin Barnard wrote:
> On Tue, 26
Sally Sally wrote:
This
existing unique field will have to be a character of fixed length
(VARCHAR(12)) because although it's a numeric value there will be
leading zeroes.
Plenty of people are contributing their tuppence-worth regarding the
choice of surrogate vs natural primary key.
Can I j
On Wed, Oct 27, 2004 at 00:10:27 +0200,
Dawid Kuroczko <[EMAIL PROTECTED]> wrote:
> 3. If you'll need things like "last 50 keys", you can SELECT * FROM
> foo ORDER BY yourserialkey DESC LIMIT 50;
You really shouldn't be doing that if you are using sequences to generate
the key. Sequences are jus
Dawid,
I am interested in the first point you made that:
having varchar(12) in every referencing table, takes more storage
space.
The thing is though, if I have a serial primary key then it would be an
additional column. Or you are saying the space taken by a VARCHAR(12) field
is more than two IN
On Thu, Oct 28, 2004 at 14:31:32 +,
Sally Sally <[EMAIL PROTECTED]> wrote:
> Dawid,
> I am interested in the first point you made that:
> having varchar(12) in every referencing table, takes more storage
> space.
> The thing is though, if I have a serial primary key then it would be an
> add
lt;[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [GENERAL] primary key and existing unique fields
Date: Thu, 28 Oct 2004 12:44:00 -0500
On Thu, Oct 28, 2004 at 14:31:32 +,
Sally Sally <[EMAIL PROTECTED]> wrote:
> Dawid,
> I am interested in the first point
20 matches
Mail list logo
