столбец в качестве первичного ключа или два внешних ключей в качестве первичного ключа

Question

У меня есть следующий проект базы данных:

E-Report имеет один QAP, который имеет некоторые Requirement с. A QAP и его Requirement s могут использоваться более чем в одном E-Report.

Каждый Requirement будет иметь подтверждение Да/Нет в каждом электронном отчете. Я добавил EReportReq для хранения значений подтверждений требований (пользователи установят эти значения).

А также, каждый Requirement будет иметь более одного Image на каждом E-Report. EReportReqImg будет хранить Image и Requirement отношений.

Если вам нужна дополнительная информация об этой модели базы данных, пожалуйста, сообщите мне.

Мой вопрос примерно EReportReq стол. Я не уверен, нужна ли мне колонка в качестве первичного ключа (EReportReqId), или я могу использовать eReportId и requirementId в качестве первичного ключа.

Если я использую эти два столбца, eReportId и requirementId как первичный ключ, мне нужно будет добавить эти два в EReportReqImg стол, так что я не знаю, если этот подход лучше, чем у меня.

Как вы думаете?

Answer 1

Давайте начнем с этого состояния:

мне нужно будет добавить эти два EReportReqImg

В общем использовании 2 FK, как PK нормальная практика для не изменяемых данных. Поэтому, если EReportReq не должен быть изменен таким образом, что вы перетащите его на другой requirementId или eReportId, тогда используйте составной ключ. В противном случае более безопасно и эффективно использовать однозначный первичный ключ - поскольку он не изменяется в течение времени, и в результате вам не нужен триггер записи или использование сложного каскада для обновления дочерних таблиц.

Другого варианта для рассмотрения является простотой результата SQL, просто лучше, чем сложные - написать INNER JOIN с 2 поля является сложной конструкцией, и есть потенциально ошибку место для пропуска одного из ключей.

Answer 2

Мой вопрос примерно EReportReq стол. Я не уверен, нужна ли мне колонка в качестве первичного ключа (EReportReqId), или я могу использовать eReportId и requirementId в качестве первичного ключа.

Вы можете использовать любой из них - ни один из них не является абсолютно «лучшим». Просто будьте осторожны, если вы решите использовать первый подход, также создайте ограничение UNIQUE на {eReportId, requirementId}.

Кулака подход (с неидентифицирующими отношениями и суррогатным ключом) приводит к следующему:

• «компактнее» внешним ключам в дочерних таблицах (что EReportReqImg в данном случае) - как уже отмечался,
• Cascading ON UPDATE не распространяется на детей (поэтому, если вы обновляете EReport.eReportId, только EReportReq.eReportId обновляется каскадом, но не EReportReqImg.eReportId)
• и может быть более дружелюбным к ORM.

С другой стороны, второй подход (с определением отношения и естественные ключи):

• потенциально имеет меньшую потребность объединения (например, вам не нужно EReportReqImg JOIN EReportReq просто найти выход requirementId - вы его прямо в EReportReqImg.requirementId)
• лучше подходит для clustered tables (например EReportReq строк с одинаковым eReportId будут храниться физически «близко», который может существенно выиграть несколько запросов)
• избегает дополнительного указателя на суррогатном ключе.

Поскольку у вас есть небольшое количество дочерних таблиц, «жир» ФКС не имеет большого значения, и так как мы имеем дело с идентификаторами, они вряд ли изменятся и каскадные ON UPDATE вряд ли будет проблемой. Итак, мой инстинкт состоит в том, чтобы пойти со вторым подходом, но у вас могут быть другие соображения, которые могут опрокинуть ваше решение в другом направлении ...