Merlin Moncure wrote:
In the context of this debate, I see this argument all the time, with
the implied suffix: 'If only we used integer keys we would not have
had this problem...'. Either the customer identifies parts with a
part number or they don't...and if they do identify parts with a
numbe
On 4/18/07, Dave Dutcher <[EMAIL PROTECTED]> wrote:
I think a database with all natural keys is unrealistic. For example if you
have a table that refers to people, are you going to use their name as a
primary key? Names change all the time due to things like marriage,
divorce, or trouble with t
On Tue, 2007-04-17 at 21:06 -0700, Craig A. James wrote:
> Merlin Moncure wrote:
> > In the context of this debate, I see this argument all the time, with
> > the implied suffix: 'If only we used integer keys we would not have
> > had this problem...'. Either the customer identifies parts with a
>
I think a database with all natural keys is unrealistic. For example if you
have a table that refers to people, are you going to use their name as a
primary key? Names change all the time due to things like marriage,
divorce, or trouble with the law. We have tables with 20 million rows which
ref
Merlin Moncure wrote:
Since the part number is NOT the primary key, duplicate part numbers
are not a problem. If you had instead used the part number as the
primary key, you'd be dead in the water.
You are redefining the primary key to be (part_number,
obsoletion_date). Now, if you had not a
On 4/18/07, Craig A. James <[EMAIL PROTECTED]> wrote:
Merlin Moncure wrote:
> In the context of this debate, I see this argument all the time, with
> the implied suffix: 'If only we used integer keys we would not have
> had this problem...'. Either the customer identifies parts with a
> part num
On Wed, 18 Apr 2007, Richard Huxton wrote:
And at the end of the day that's the root of the problem. It's easy to be
lulled into "well it looks like a primary key" rather than being able to
guarantee it.
In some of these cases it is guaranteed to be a primary key given all
available informat
Craig A. James wrote:
Since we're only aggregating information, we have
no control over the data that these companies provide.
And at the end of the day that's the root of the problem. It's easy to
be lulled into "well it looks like a primary key" rather than being able
to guarantee it.
--
Merlin Moncure wrote:
In the context of this debate, I see this argument all the time, with
the implied suffix: 'If only we used integer keys we would not have
had this problem...'. Either the customer identifies parts with a
part number or they don't...and if they do identify parts with a
numbe
On 4/16/07, Greg Smith <[EMAIL PROTECTED]> wrote:
I think the point Craig was trying to make is that what you refer to here
as "extraordinary cases" are, in fact, rather common. I've never seen a
database built on natural keys that didn't at some point turn ugly when
some internal or external bu
On Mon, 16 Apr 2007, Merlin Moncure wrote:
extraordinary cases do happen, like a company overhauling its numbering
systems, but such cases can be dealt with by a number of methods
including letting RI do its thing.
I think the point Craig was trying to make is that what you refer to here
as
Craig A. James wrote:
> Merlin Moncure wrote:
>> Using surrogate keys is dangerous and can lead to very bad design
>> habits that are unfortunately so prevalent in the software industry
>> they are virtually taught in schools. ... While there is
>> nothing wrong with them in principle (you are ex
On 4/16/07, Craig A. James <[EMAIL PROTECTED]> wrote:
Merlin Moncure wrote:
> Using surrogate keys is dangerous and can lead to very bad design
> habits that are unfortunately so prevalent in the software industry
> they are virtually taught in schools. ... While there is
> nothing wrong with t
Merlin Moncure wrote:
Using surrogate keys is dangerous and can lead to very bad design
habits that are unfortunately so prevalent in the software industry
they are virtually taught in schools. ... While there is
nothing wrong with them in principle (you are exchanging one key for
another as a
On 4/14/07, Bill Moran <[EMAIL PROTECTED]> wrote:
In response to "Kynn Jones" <[EMAIL PROTECTED]>:
> The two situations are semantically identical: each record in table bar
> refers to a record in table foo. The difference is that in the first
> schema, this referencing is done through an "artif
In response to "Kynn Jones" <[EMAIL PROTECTED]>:
> Consider these two very similar schemas:
>
> Schema 1:
>
>
> CREATE TABLE foo (
> id serial PRIMARY KEY,
> frobnitz character(varying 100) NOT NULL UNIQUE
> );
>
>
> CREATE TABLE bar (
> id serial PRIMARY KEY,
> foo_id int REFERENCES
Consider these two very similar schemas:
Schema 1:
CREATE TABLE foo (
id serial PRIMARY KEY,
frobnitz character(varying 100) NOT NULL UNIQUE
);
CREATE TABLE bar (
id serial PRIMARY KEY,
foo_id int REFERENCES foo(id)
)
Schema 2:
CREATE TABLE foo (
frobnitz character(varying 100) PRIMA
17 matches
Mail list logo
