Can I use identity for primary key in more than one table in the same ER model

Question

As it is said in the title, my question is can I use int identity(1,1) for primary key in more than one table in the same ER model? I found on Internet that Primary Key need to have unique value and row, for example if I set int identity (1,1) for table:

CREATE TABLE dbo.Persons 
(
    Personid int IDENTITY(1,1) PRIMARY KEY,
    LastName varchar(255) NOT NULL,
    FirstName varchar(255),
    Age int 
);
GO

and the other table

CREATE TABLE dbo.Job 
(
    jobID int IDENTITY(1,1) NOT NULL PRIMARY KEY,
    nameJob NVARCHAR(25) NOT NULL,
    Personid int FOREIGN KEY REFERENCES dbo.Persons(Personid)
);

Wouldn't Personid and jobID have the same value and because of that cause an error?

Answer 1

Constraints in general are defined and have a scope of one table (object) in the database. The only exception is the FOREIGN KEY which usually has a REFERENCE to another table.

The PRIMARY KEY (or any UNIQUE key) sets a constraint only on the table it is defined on and is not affecting or is not affected by other constraints on other tables.

The PRIMARY KEY defines a column or a set of columns which can be used to uniquely identify one record in one table (and none of the columns can hold NULL , UNIQUE on the other hand allows NULL s and how it is treated might differ in different database engines).

So yes, you might have the same value for PersonID and JobID , but their meaning is different. (And to select the one unique record, you will need to tell SQL Server in which table and in which column of that table you are looking for it, this is the table list and the WHERE or JOIN conditions in the query).

The query SELECT * FROM dbo.Job WHERE JobID = 1; and SELECT * FROM dbo.Person WHERE PersonID = 1; have a different meaning even when the value you are searching for is the same.

You will define the IDENTITY on the table (the table can have only one IDENTITY column). You don't need to have an IDENTITY definition on a column to have the value 1 in it, the IDENTITY just gives you an easy way to generate unique values per table .

You can share sequences across tables by using a SEQUENCE , but that will not prevent you to manually insert the same values into multiple tables.

In short, the value stored in the column is just a value, the table name, the column name and the business rules and roles will give it a meaning.

---

To the notion "every table needs to have a PRIMARY KEY and IDENTITY , I would like to add, that in most cases there are multiple (independent) keys in the table. Usually every entity has something what you can call business key , which is in loose terms the key what the business (humans) use to identify something. This key has very similar, but usually the same characteristics as a PRIMARY KEY with IDENTITY .

This can be a product's barcode, or the employee's ID card number, or something what is generated in another system (say HR) or a code which is assigned to a customer or partner.

These business keys are useful for humans, but not always useful for computers, but they could serve as PRIMARY KEY .

In databases we (the developers, architects) like simplicity and a business key can be very complex (in computer terms), can consist of multiple columns, and can also cause performance issues (comparing a strings is not the same as comparing numbers, comparing multiple columns is less efficient than comparing one column), but the worst, it might change over time. To resolve this, we tend to create our own technical key which then can be used by computers more easily and we have more control over it, so we use things like IDENTITY s and GUID s and whatnot.