Могу ли я использовать один и тот же первичный ключ в двух разных таблицах? - PullRequest
Новая
       2

Могу ли я использовать один и тот же первичный ключ в двух разных таблицах?

0 голосов
/ 11 апреля 2019

'' 'CREATE TABLE Employee (employeeID INT (10) ПЕРВИЧНЫЙ КЛЮЧ, имя CHAR (20));'' '

' '' CREATE TABLE SALARY (employeeID INT (10) PRIMARY KEY, Salary INT (10));'' 'Можно ли использовать один и тот же первичный ключ в обеих таблицах?

Ответы [ 5 ]

2 голосов
/ 11 апреля 2019

Если у вас есть вопрос, можете ли вы использовать один и тот же столбец EMPLOYEEID в качестве основного идентификатора для нескольких таблиц, ответ «ДА, ВЫ МОЖЕТЕ»

Вы можете использовать один и тот же столбец в качестве основного индекса для нескольких таблиц, но вы не можете иметь более одного первичного индекса в таблице

0 голосов
/ 11 апреля 2019

Да, вы можете. Вы должны сделать salary.employeeid как первичный ключ таблицы, так и внешний ключ для таблицы сотрудника: 

CREATE TABLE salary
(
  employeeid INT (10) NOT NULL,
  salary INT (10) NOT NULL,
  CONSTRAINT pk_salary PRIMARY KEY (employeeid,
  CONSTRAINT fk_salary_employeeid FOREIGN KEY (employeeid) REFERENCES employee (employeeid)
);

Это создает отношение {1}: {0,1} между таблицами и гарантирует, что вы не можете хранить зарплату, не сохранив сотрудника, и что вы не можете сохранить более одной зарплаты для одного сотрудника.

Это то, что мы редко делаем. (Мы бы предпочли сделать зарплату столбцом в таблице сотрудников.) Единственное преимущество отдельной таблицы зарплат, которую я вижу, состоит в том, что вы можете предоставить права на таблицу сотрудников, но отозвать их на таблице зарплат, чтобы создать таблицу зарплат. невидим для некоторых пользователей базы данных.

0 голосов
/ 11 апреля 2019

Вы можете сделать это, однако, это плохой дизайн.

Я бы предложил использовать EmployeeId в качестве PK на таблице сотрудников и EmployeeId в качестве внешнего ключа на таблице Salary, при этом таблица Salary имеет свой собственный PK (наиболее вероятно SalaryId).

Также поле [Имя], которое я бы лично избегал, поскольку «Имя» - зарезервированное слово в SQL. 

    CREATE TABLE dbo.Employee
    (
     EmployeeId BIGINT IDENTITY(1,1)
    ,EmployeeName VARCHAR(20) NOT NULL
    ,CONSTRAINT PK_Emp PRIMARY KEY (EmployeeId)
    );
    GO

    CREATE TABLE dbo.Salary
    (
     SalaryId BIGINT IDENTITY(1,1)
    ,EmployeeId BIGINT NOT NULL
    ,Salary INT NOT NULL
    ,CONSTRAINT PK_Sal PRIMARY KEY (SalaryId)
    ,CONSTRAINT FK_EmpSal FOREIGN KEY (EmployeeId)
        REFERENCES Employee(EmployeeId)
    );
    GO

С учетом всего вышесказанного, я думаю, что нужно немного больше подумать о структуре БД, и вам, скорее всего, следует в итоге получить 3 таблицы. Вполне вероятно, что у многих сотрудников будет одинаковая зарплата, скажем, 5 сотрудников на 40 000, 3 на 50 000 и т. Д. Вы в конечном итоге будете хранить одно и то же значение зарплаты несколько раз.

Лучший способ - сохранить это значение один раз и создать третью таблицу, которая связывает сотрудника с заработной платой (в данном случае я назвал это [Заработок]). С этой структурой зарплата, скажем, 40000 хранится 1 раз в БД, и вы можете связать с ней employeeId несколько раз. 

    CREATE TABLE dbo.Employee
    (
     Id BIGINT IDENTITY(1,1)
    ,EmployeeName VARCHAR(20) NOT NULL
    ,CONSTRAINT PK_Emp PRIMARY KEY (Id)
    );
    GO

    CREATE TABLE dbo.Salary
    (
     Id BIGINT IDENTITY(1,1)
    ,Salary INT NOT NULL
    ,CONSTRAINT PK_Sal PRIMARY KEY (Id)
    );
    GO

    CREATE TABLE dbo.Earnings
    (
     Id BIGINT IDENTITY(1,1)
    ,EmployeeId BIGINT NOT NULL
    ,SalaryId BIGINT NOT NULL
    ,CONSTRAINT PK_Ear PRIMARY KEY (Id)
    ,CONSTRAINT FK_EmpEar FOREIGN KEY (EmployeeId)
        REFERENCES Employee(Id)
    ,CONSTRAINT FK_SalEar FOREIGN KEY (SalaryId)
        REFERENCES Salary(Id)
    );
    GO
0 голосов
/ 11 апреля 2019

Да. Вы можете иметь одинаковое имя столбца в качестве первичного ключа в нескольких таблицах.

Имена столбцов в таблице должны быть уникальными. Таблица может иметь только один первичный ключ, так как она определяет целостность объекта .

Если этот вопрос касается моделирования данных родительско-дочерних отношений, существует два типа. Вы читаете больше по этому вопросу.

  1. Идентификационные отношения : Ребенок идентифицирует себя с помощью родителя. Здесь сотрудник и зарплата будет использовать один и тот же первичный ключ. Первичный ключ родительской таблицы (EmployeeId) также будет первичным ключом дочерней таблицы (Salary).
  2. Неидентифицирующие отношения : Ребенок имеет свою собственную личность. Здесь у Employee & Salary будет другой первичный ключ. Дочерняя таблица будет иметь свой собственный первичный ключ (скажем, SalaryId) и будет иметь первичный ключ родителя в качестве внешнего ключа (EmployeeId).
0 голосов
/ 11 апреля 2019

Технически это возможно. Тем не менее, желательно использовать внешний ключ. Это будет:

- Избегайте избыточности

-Помощь в поддержании структуры БД

-Улучшение читаемости

Для этого примера используйте: 

CREATE TABLE Employee ( EmployeeID INT PRIMARY KEY, Name CHAR (20), Primary Key (EmployeeId) );

CREATE TABLE SALARY ( SalaryId INT , EmployeeID INT , Salary INT (10), Primary Key (SalaryId), Foreign Key (EmployeeId) REFERENCES Employee );

* Еще лучшим подходом было бы добавить ограничение вместо простого упоминания

[ключевые имена] Как: 

CREATE TABLE Employee(
EmployeeId INT,
Name CHAR(20)
)

ALTER TABLE Employee ADD CONSTRAINT PK_EmployeeId PRIMARY KEY
...