I am designing a project based database for the first time and need some advice on how best to determine whether to use a single primary key or composite primary key?
We have many existing separate project based databases but have never combined them into one, even though they follow the same structure.
All tables are based on 2 main fields
1) Project code
2) Item number
These always go together and are present in all tables. Both the project code and the item code are very meaningful to every user because they will be describing physical objects which are identified by their project code and item number (actually written on them).
The project code is always unique whereas the item number ranges from 1 to n (where n is any number but never repeated). Start a new project and the item number starts at 1 again.
So the basis of the database is as follows.
Table: Project List
Fields: Project Code (PK), other fields...
Table: Item list
Fields: Project code (FK), Item number (PK?), other fields...
Table: any other table
Fields: Project code (FK), Item number (FK?), other fields...
It makes sense to me to have the Project code as a primary key However the item code can't be a primary key as it is not unique. Item numbers 1-n will be repeated every project but is the main reference to everyone.
My first thought would be to create a surrogate primary key called Item_ID which auto increments in the item list table and then use that as a foreign key in all other tables,
so... it would look like
Table: Project List
Fields: Project Code (PK), other fields...
Table: Item list
Fields: Project code (FK), Item_ID (PK), Item number, other fields...
Table: any other tables
Fields: Project code (FK), Item_ID (FK), Item number, other fields...
However the item_ID key would be meaningless to everyone using it and they would have to keep asking what ID number is my item number in order to link it to its parent table.
My second thought was to make the item number unique by adding the project code to the item number in the formula PROJECT CODE_ITEM NUMBER E.G. if the project code is "Project1" then the item number could be written "Project1_24". That would make item number unique and therefore can be used as a primary key.
(Just assume the child tables have their own PK's).
So they would look like this:
Table: Project List
Fields: Project Code (PK), other fields...
Table: Item list
Fields: Project code (FK), Item number (PK), other fields...
Table: any other tables
Fields: Project code (FK), Item number (FK), other fields...
This works as it still retains the item number which is meaningful to every user. But it seems a bit long winded as they would have to enter PROJECT CODE_ITEM NUMBER each time to make the correct reference. They are used to just writing the item number.
..maybe there is some way of automating this process so they can still write in the number but the database adds the project code behind it..I don't know?
My third idea is to make Project code and item number a composite key in the item list table and create a surrogate key for the project code in the project list table.
So it looks like this:
Table: Project List
Fields: Project_ID (PK), other fields...
Table: Item list
Fields: Project_ID (FK), Project code (CPK), Item number, (CPK), other fields...
Table: any other table
Fields: Project_ID (FK), Project code (CFK), Item number, (CFK), other fields...
This would be ok as entering the project ID would be fairly straight forward and project code and item number makes a natural key in when used in combination. They will always go together in any record and be unique.
But which method should I use?
