Is it better to have a single primary key, or use composite primary keys (usually, they are combination of one primary key and foriegn keys). I have examples below:
Composite Primary Key example:
AMeta
--- AMetaId - Primary Key
--- AMetaText
BMeta
--- BMetaId - Primary Key
--- AMetaID - Foreign Key to Table AMeta
--- BMetaText
A
--- AId - Primary Key
--- AMetaId - Primary Key and Foreign Key to Table AMeta
--- AText
B
--- BId - Primary Key
--- BMetaId - Primary Key Foreign Key to Table BMeta
--- AId - Primary Key and Foreign Key to Table A
--- BText
Single Primary Key example:
AMeta
--- AMetaId - Primary Key
--- AMetaText
BMeta
--- BMetaId - Primary Key
--- AMetaId - Foreign Key to Table AMeta
--- BMetaText
A
--- AId - Primary Key
--- AMetaId - Foreign Key to Table AMeta
--- AText
B
--- BId - Primary Key
--- BMetaId - Foreign Key to Table BMeta
--- AId - Foreign Key to Table A
--- BText
Which is the better Database Design?
I genereally tend to use single-column primary keys almost exclusively - either there is a good natural key available (pretty rarely), or then I add a surrogate INT IDENTITY key to the table.
My main reasons are:
the primary key needs to be unique, non-null at all times
the primary key is the clustering key in SQL Server by default, which adds stable (non-changing), narrow (4 bytes max.) and preferably ever-increasing to the list of criteria
with a single column primary key, all my foreign keys are also easy to use single columns - I don't like having to join two tables on 3, 5 or even more columns just to get the join to work, which is exactly what happens if you have a compound primary key
The first scheme makes no sense, because it implies (and allows) that there can be multiple rows in Table B with the same BId value but with different values of AId, and there is no meaning associated with column Bid. Is it a FK to somewhere else? If so, to what? If not, what is generating it ? What does it mean?
The second scheme, on the other hand, is logically consistent, but implies that rows in Table B can be associated with two different rows in Table AMeta,
through Table B using the FK Column
BMetaId and from there to Table
AMeta using TableB.AMetaId, and
Through table BMeta using column
BMetaId to Table BMeta and from
there to AMeta using BMEta.AMetaId
Is this really an accurate representation of your business domain model?
Related
In SQL Server, can a table have primary key on 1 column and then composite keys on other two or more columns?
Yes.
A table can have more than one Key, and a Key has one or more key columns.
In SQL Server you create a Key with any of a UNIQUE CONSTRAINT, a PRIMARY KEY CONSTRAINT, or a UNIQUE INDEX. A table can at most one PRIMARY KEY CONSTRAINT, but can have any number of UNIQUE CONSTRAINTs or UNIQUE INDEXs.
So yes, a table can have a PRIMARY KEY on one column, and a composite UNIQUE INDEX or UNIQUE CONSTRAINT.
I am working on an assignment and we are supposed to:
based on this schema:
Underlined = primary key, both underlined = composite key
My question is for the composite keys, are the two attributes that make up the composite key, as in table Borrower, also considered foreign keys?
Yes, it is possible to have a composite primary key for a table that are also considered foreign keys. If you do something like the following in SQL it would work properly.
CREATE TABLE Borrower
(
customerID VARCHAR2(10),
loan_number VARCHAR2(10),
PRIMARY KEY(customerID, loan_number),
FOREIGN KEY customerID REFERENCES Customer(CustomerID),
FOREIGN KEY loan_number REFERENCES Loan(loan_number)
);
The important thing to keep in mind is that the data type of the keys in the Borrower table have to match exactly the data types of the keys in the Customer and Loan tables respectively.
I have a table in my database that models a m-to-n relation. The primary key of this relation is of course the combined primary keys of the 2 entities involved in this relation.
The relation goes like this: m customers have n orders
create table customer(
cid SERIAL PRIMARY KEY,
...
);
create table order(
oid SERIAL PRIMARY KEY,
...
);
create table has(
oid INTEGER REFERENCES order(oid) ON DELETE CASCADE,
cid INTEGER REFERENCES customer(cid) ON DELETE CASCADE,
FOREIGN KEY (oid,cid) or PRIMARY KEY (oid,cid)
);
I'm a bit confused on what to use here: primary key or foreign key to put them in relation?
thanks in advance for any help.
Jaiel
You should be using PRIMARY KEY for the composite key in table has. The combination of the order and customer IDs in the has table is a primary key in that table, because it allows the identification of a unique single record.
Note that both oid and cid in table has are foreign keys, pointing to the order and customer tables, respectively.
hello I have nine tables in database Two of the tables in the database are:
tbl_unit
--------
Unit_Number(pk),
Floor_Number(pk),
Apartment_plaque(pk),
BedRoom_Count,
BathRoom_Count,
Rental_Fees_Unit,
Unit_Area,
Unit_state
and
tbl_payment
-----------
Renter_National_Code(pk),
Apartment_Plaque(pk),
Floor_Number(pk),
Unit_Number(pk),
Owner_National_Code,
Payment_Date,
Debt,
Other_Amounts,
Other_amounts_comment,
amount_of_payment
I can't determine the none of primary key's in tbl_payment as foreign key for primary key's in tbl_unit and i recieve "both sides of a relationship must have the same number of columns" error
What's the problem?
A table can have only one primary key. Your tbl_payment table has a composite primary key consisting of 4 columns while the tbl_unit table has a composite primary key of 3 columns.
I believe you want a foreign key on the tbl_payment table to relate a payment to a specific unit. In that case, add a 3-column foreign key on tbl_payment referencing the primary key of tbl_units:
ALTER TABLE dbo.tbl_payment
ADD CONSTRAINT fk_tbl_payment_tbl_unit
FOREIGN KEY (
Unit_Number
, Floor_Number
, Apartment_plaque
)
REFERENCES dbo.tbl_unit(
Unit_Number
, Floor_Number
, Apartment_plaque
);
I am trying to add a foreign key constraint to a table in my PostgreSQL 8.4 database, but it is failing as the target field, though part of a multi-column primary key, is not in itself unique.
The database has the following structure:
Table 1 (names of primary IDs):
PrimaryType, Name
[Primary key = "PrimaryType"]
Table 2 (names of child IDs for each type of primary ID):
PrimaryType, SubType, Name
[Primary key = "PrimaryType, SubType"]
[Foreign key = "Table2.PrimaryType = Table1.PrimaryType"]
Table 3 (logs which include a primary and child ID):
PrimaryType, SubType, DATA1, DATA2, ..., DATAN
[Foreign key = "Table3.PrimaryType = Table1.PrimaryType" AND "Table3.SubType = Table2.SubType"]
Obviously, the second part of the foreign key for table 3 is what is causing the problem. I just need to ensure that the primary and subtype ID pair in the log is a valid combination.
Thanks in advance.
For table 3's foreign key, change:
foreign key PrimaryType references Table1(PrimaryType)
foreign key SubType references Table2(Subtype)
to
foreign key (PrimaryType, SubType) references Table2(PrimaryType, SubTYpe)