Home/ Questions/Q 986751
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T05:22:13+00:00

How should columns in a database table that have a PK/FK relationship be named?

  • 0

How should columns in a database table that have a PK/FK relationship be named? Should their names contain a reference to the table they are in? Consider the examples below. Each employee has an ID which is a FK in the salaries table.

/* Employees Option 1*/
CREATE TABLE dbo.Employees 
( 
    EmployeeID INT PRIMARY KEY, 
    EmployeeFirstName VARCHAR(32), 
    EmployeeLastName VARCHAR(32), 
    EmployeeEmail VARCHAR(255) -- , ... 
)


/* Employees Option 2*/
CREATE TABLE dbo.Employees 
( 
    EmployeeID INT PRIMARY KEY, 
    FirstName VARCHAR(32), 
    LastName VARCHAR(32), 
    Email VARCHAR(255) -- , ... 
)

/* Employees Option 3*/
CREATE TABLE dbo.Employees 
( 
    ID INT PRIMARY KEY, 
    FirstName VARCHAR(32), 
    LastName VARCHAR(32), 
    Email VARCHAR(255) -- , ... 
)

/* Salaries Option 1*/
CREATE TABLE dbo.Salaries 
( 
    EmployeeID INT, 
    Salary INT
)

/* Salaries Option 2*/
CREATE TABLE dbo.Salaries 
( 
    Employee INT, 
    Salary INT
)

I have more experience with object oriented programing then database design. With OOP when naming properties of a class you would not want to repeat the name of the class as it would be redundant (Employee.ID not Employee.EmployeeID). Thus off hand I think Employee Option 3 and Salaries Option 1 above would be best, as this how I would name properties of classes in OOP

Am I right? Is there something else I should be considering that applies to database design that does not apply to OOP?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The ISO 11179 has some good things to say about naming. I recommend it.

    Data elements should always be named for what they are, not by their place in a structure. Also they should be unique within the namespace, schema or other context in which they appear. The names should contain only commonly understood abbreviations.

    On that basis EmployeeID is a reasonable name for an employee identifier. ID is a bad name because it tells you nothing useful.

    Also, it is a very widely observed convention that foreign key attributes should be named the same as the key attributes they reference (because usually they are implicitly the same data element – just in different tables). The only time I would usually break that rule is if a single table contains two foreign keys referencing the same column in another table. In that case the names obviously need to be different to avoid a naming conflict.

    • 0