Florian,
> Or you create a classifier_1 and a classifier_2 table, each containing
> only the column "code". Then you can drop the "category1" and "category2"
> fields from "info", and just point the foreign keys to the correct table.
Thank you.
I will probably go by this way.
> You can, optio
Thomas F.O'Connell wrote:
Referential integrity never dictates the need for "dummy" columns. If
you have a column that you need to refer to a column in another table so
strongly that you want the values always to be in sync, you create a
foreign key, establishing referential integrity between a
Andrus Moor wrote:
thank you for reply. There was a typo in my code. Second table should be
CREATE TABLE info (
code1 CHAR(10),
code2 CHAR(10),
FOREIGN KEY ('1', code1) REFERENCES classifier,
FOREIGN KEY ('2', code2) REFERENCES classifier
);
I try to explain my problem more precicely.
I can i
seems
like they might not be even needed?
Not sure if that is what you are asking?
Oisin
- Original Message -
From: "Thomas F.O'Connell" <[EMAIL PROTECTED]>
To: "Andrus Moor" <[EMAIL PROTECTED]>
Cc:
Sent: Monday, March 28, 2005 10:35
Subject: Re:
Andrus, it's still not clear to me that you're understanding the role
of referential integrity in database design. It exists to guarantee
that the values in a column in a given table correspond exactly to the
values in a column in another table on a per-row basis. It does not
exist to guarantee
Thomas,
thank you for reply. There was a typo in my code. Second table should be
CREATE TABLE info (
code1 CHAR(10),
code2 CHAR(10),
FOREIGN KEY ('1', code1) REFERENCES classifier,
FOREIGN KEY ('2', code2) REFERENCES classifier
);
I try to explain my problem more precicely.
I can implemen
It's somewhat unclear what you're attempting to do, here, but I'll give
a shot at interpreting. Referential integrity lets you guarantee that
values in a column or columns exist in a column or columns in another
table.
With classifier as you've defined it, if you want referential integrity
in
