Как правильно использовать составные первичные ключи в таблицах?

Question

[Fox 777]

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

Я разрабатываю проект, в котором требуется связывать несколько таблиц между собой через промежуточные таблицы. Например, есть таблицы Staff, Services и промежуточная таблица StaffServices, которая связывает сотрудников с услугами, которые они предоставляют. Вот пример структуры таблицы:

CREATE TABLE StaffServices (
    staffId INT,
    serviceId INT,
    PRIMARY KEY (staffId, serviceId),
    FOREIGN KEY (staffId) REFERENCES Staff(id),
    FOREIGN KEY (serviceId) REFERENCES Services(id)
);

Также есть аналогичные промежуточные таблицы для связи между другими сущностями:

CREATE TABLE StaffBusiness (
    staffId INT,
    businessId INT,
    PRIMARY KEY (staffId, businessId),
    FOREIGN KEY (staffId) REFERENCES Staff(id),
    FOREIGN KEY (businessId) REFERENCES Businesses(id)
);

CREATE TABLE StaffBusinessSchedules (
    staffId INT,
    businessId INT,
    scheduleId INT,
    PRIMARY KEY (staffId, businessId, scheduleId),
    FOREIGN KEY (staffId) REFERENCES Staff(id),
    FOREIGN KEY (businessId) REFERENCES Businesses(id),
    FOREIGN KEY (scheduleId) REFERENCES Schedules(id)
);

Хотелось бы получить рекомендации и узнать мнение сообщества по следующим вопросам:

1. Насколько правильным и общепринятым является использование составных первичных ключей в таких случаях?
   
2. Какие могут быть плюсы и минусы данного подхода?
   
3. Есть ли альтернативы, которые стоит рассмотреть в подобных ситуациях?
   
4. Как это влияет на производительность базы данных и целостность данных?
   
5. Какие best practices существуют для таких случаев?
   
6. Буду рад услышать ваши мнения и советы!
   

Заранее спасибо за помощь!

Comments

[Akina]

Как правило, три и более внешних ключей в одной связующей таблице, ссылающихся на сущность, а не на словарь - это ошибка проектирования.

Answer 1

[elderl]

Вполне достаточно обычный ID (с автоувеличением). А уникальность поддерживать соответствующим индексом.

Answer 2

[Everything_is_bad]

По опыту, в подавляющем большинстве случаев, используют суррогатный первичный ключ, а если хочешь именно составной первичный ключ, ты точно должно понимать и главное доказать, почему нужен именно он.