Использование первичного и внешнего ключей в диаграмме EER

Question

В моей БД у меня есть три таблицы (у меня больше, но на случай, если пользователи равны, пользователи могут быть компаниями или одинокими людьми).

• Users имеет первичный ключ id_user;
• Company имеет первичный ключ id_company и внешний ключ users_id_user;
• job_offers имеет первичный ключ id_job_offers и два внешних ключа: company_id_company и company_users_id_user.

Мои вопросы:

1. Имеет ли смысл первичный ключ в job_offers?Я не думаю, что для этого есть причина.
2. job_offers имеет два внешних ключа, один из которых относится к company, а другой к users.Есть ли проблема с этим?Существует ли другой способ выполнить ту же задачу?

Answer 1

Все таблицы должны иметь первичный ключ. Звучит так, будто вы спрашиваете, должен ли ваш первичный ключ быть суррогатным ключом или натуральным ключом .

Вы можете задать тот же вопрос и другим вашим столам. Например, если столбец email в таблице users является обязательным и уникальным, его можно использовать в качестве (естественного) первичного ключа.

Этот вопрос довольно активно обсуждается, и оба подхода могут работать (как и смешанный подход). Если вы хотите ознакомиться с этой темой в целом, выполните поиск в Google по запросу «Натуральный ключ против суррогатного ключа».

Answer 2

Имеет ли первичный ключ смысл в job_offers?Я не думаю, что для этого есть причина.

Да.Я согласен, что у каждого стола должен быть свой ПК. Должна ли каждая таблица иметь первичный ключ?

У меня есть больше, но в случае совпадения пользователи могут быть компаниями или одинокими людьми

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

В системе есть два типа пользователей: обычный пользователь (человек) и пользователь компании.Job_offers - это таблица, в которой сохраняются предложения о работе от компании.Если пользователь компании хочет опубликовать работу, запись будет вставлена ​​в таблицу job_offers.Затем, как только обычный пользователь получит это предложение о работе, для идентификатора пользователя этого обычного пользователя будет назначен job_offers.company_user_id_user.

Но из вашей диаграммы ER Company.users_id_user - это PK, который не может бытьnull, и этот PK используется в job_offers.company_users_id_user как FK.Таким образом, job_offers.company_users_id_user также не может быть нулевым.

В результате он не может справиться с ситуацией, когда пользователь компании просто публикует работу и до того, как обычный пользователь получит это предложение о работе, или никто не получит это предложение о работе в конце концов.В этом случае для job_offers.company_users_id_user должно быть установлено значение null, что нарушает ограничение job_offers.company_users_id_user not null.

Я выполню ту же задачу, используя этот дизайн:

Users
=================
id_user (PK)
email 
activation
password

Company
=================
id_company (PK)
activities 
foundation 
user_id (FK to Users)
description

job_offer
=================
id_job_offer (PK)
id_company (FK to Company)
description_offer 
tags

user_offer
=================
id (PK)
user_id (FK to Users)
job_offer_id (FK to job_offer)

Answer 3

1) имеет смысл первичный ключ в Предложения о работе? Я думаю, что нет никаких оснований

Да, есть - у каждой таблицы должен быть первичный ключ. Это называется «нормализация».

Ваш выбор может быть не очень хорошим. Я бы сказал, что два внешних ключа вместе должны быть первичным ключом, а не столбцом id.

2) В предложениях о работе есть два иностранных ключи, один связан с компанией и другой для пользователей, есть проблемы? существует другой способ (лучший способ) сделать это?

Нет, именно так строятся отношения многие ко многим.

Answer 4

1. Я думаю, что ты прав. Там нет необходимости в отдельном поле id. Два внешних ключа должны вместе составлять первичный ключ таблицы.
2. Хорошо выглядит для меня.