-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello, all --
...and then David T-G said...
%
% I apologize in advance for asking kindergarten-level questions on the
% list, but my head is getting really bruised from this one. I'm trying to
I still don't understand it all ;-) but I have a
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 09, 2002 6:00 PM
To: Jon Frisby
Subject: Re: RE: relational is relational is relational, but ...
Your message cannot be posted because it appears to be either spam or
simply off
Really, the issue is that you don't want a primary key that is volatile.
It doesn't matter if it has business meaning.
Or user meaning, ie users find them useful signs. Fair enough, but if you
take that as a rationale for choosing PK values that begin by having meaning
to users, you leave your
On Tue, 3 Dec 2002, Jon Frisby wrote:
However, from a DB design standpoint, it is generally considered
MASSIVELY unwise for your PRIMARY KEY value to have any
business-meaning. If it has no business-meaning, it never needs to
change. Ever.
Really, the issue is that you don't want a primary
David,
Not bang on. A foreign key is a key which is the value of a key from a
'parent' table. In MySQL, if the table and its parent are InnoDB, the db
will prevent you from editing the parent key 'out of sync' as you say.
PB
-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi again,
What you're asking for is the ON CHANGE CASCADE behavior of FOREIGN
KEYs, and I don't know if InnoDB supports this.
However, from a DB design standpoint, it is generally considered
MASSIVELY unwise for your PRIMARY KEY value to have any
business-meaning. If it has no business-meaning, it never
MySQL supports using InnoDB tables.
CREATE TABLE customers (
num INT PRIMARY KEY,
Name VARCHAR(50) NOT NULL);
CREATE TABLE sales(
Product VARCHAR(15) NOT NULL,
Price DOUBLE NOT NULL,
Cust INT NOT NULL,
# PRIMARY KEY definition goes here,
INDEX (Cust),
FOREIGN KEY(Cust) REFERENCES customers(num)
