Re: Do I need a PK on a join table?
Date: 14 Feb 2006 10:28:57 -0800
Message-ID: <1139941737.741489.170880_at_g14g2000cwa.googlegroups.com>
By definition any table has to have a key. You can use the PRIMARY KEY constraint OR a NOT NULL unique constraint. some products make assumptions about PRIMARY KEY constraints AND sql willuse it AS a DEFAULT in a REFERENCES clause
CREATE TABLE Clients -- I assume more than one
(client_id INTEGER NOT PRIMARY KEY,
.. );
CREATE TABLE Products - more than one?
(product_id INTEGER NOT NULL PRIMARY KEY,
..);
Client_Product is a horrible name, even in an example!
CREATE TABLE Purchases
(client_id INTEGER NOT NULL
REFERENCES Clients (client_id),
product_id INTEGER NOT NULL
REFERENCES Products (product_id),
PRIMARY KEY (client_id, product_id),
.. )
Wrong. Back to the basics; all tables have to have a key. Otherwise, you have not enforced your business rules and are depending on all future users to do your job for you in their application code.
>> can't I accomplish the same thing by just creating a unique index on client_product? <<
Sure, if you do not like to write Standard SQL or portable code.
>> if I'm not interested in any help from an index, I could just create a unique constraint without a PRIMARY KEY: <<
Watch for NULLs in such keys.
First of all, fields and columns are totally different concepts. Secondly, a key is abstract and an index is only one of many ways to implement it. You have logical and physical levels all crossed up.
>> If you don't have any FOREIGN KEYs that reference a PRIMARY KEY (no RI), what's the point of the PRIMARY KEY other than enforcing uniqueness? <<
Isn't that enough? It is called data integrity.
>> If all you want to do is enforce uniqueness, why not a unique index or unique constraint only? <<
Because a PRIMARY KEY is guaranteed to be NOT NULL, portable and to be the default for REFERENCES clauses. Received on Tue Feb 14 2006 - 19:28:57 CET