Как реализовать правильную структуру таблицы сотрудников, работодателей?

Question

[entermix]

Есть таблица пользователей, каждый пользователь может выступать как работодателем, так и сотрудником одновременно, какая структура таблиц правильная?

1. Использовать 1 таблицу:
- jobs = id, user_id, employer_id, post

2. Использовать 2 таблицы:
- jobs = id, user_id, post
- employers = user_id, job_id

3. Еще вариант?

Нужно будет выводить список сотрудников, работодателей, cотрудников всех своих работодателей

Answer 1

[Максим Кудрявцев]

Для начала нужно определить сущности системы. У Вас я их вижу две: человек(user) и работа(job).

Теперь, Ваш юзер создает проект(project), выступая работодателем. Для проекта мы должны запомнить работодателя, для начала. Значит пока будет таблица job: id, id_user

Далее, на каждую работу работодатель назначает исполнителей. Не пихайте список исполнителей в таблицу project, замучаетесь потом обрабатывать данные по исполнителем. Создайте таблицу project_performer : id_project, id, id_user

Итого, у нас получается 3 таблицы:
1)Пользователи системы: user - id, логин, соль, пароль, мыло и т.п.
2)Работа(проекты): job: id, id_user, desc и т.д.
3)Исполнители работы: project_performer : id, id_project, id_user,

Теперь Ваши запросы
1)Отобразить всех работодателей. Работодателем будет юзер, если его id есть в таблице job
2)Отобразить всех сотрудников. Сотрудником будет юзер, если его id есть в таблице project_performer
3)Отобразить всех сотрудников конкретного работодателя.
select user.* from user, job, project_performer where job.id_user = id_пользователя_работодателя AND job.id = project_performer.id_project AND project_performer.id_user = user.id

4)Все работодатели, с которыми когда-либо работал исполнитель
select user.* from user, job, project_performer where project_performer.id_user = id_пользователя_исполнителя AND project_performer.id_project = job.id AND job.id_user = user.id

За корректность запросов на 100% не ручаюсь

Comments

[entermix]

Спасибо, а если реализовать так, как я предложил в первом варианте, это неправильно с точки зрения проектирования БД?

[Максим Кудрявцев]

Смотри, в твоем решении на 1 работу может быть назначен только 1 исполнитель. Я не увидел пункта где говорится "только один исполнитель".

Я отталкивался от того, что на одну работу может быть назначено 2 и более исполнителей, к примеру, типичная ситуация, один кодер пишет фронт-энд, второй бэк-энд.

Как ты это реализуешь в своей логике? Сериализация массива и перевод его в json? Решение, но не лучшее(...говнокод...). К примеру подумай как ты список сотрудников по работодателям будешь вытаскивать из сериализованного массива...

Вообще при проектировании любой БД лично я исхожу из 3-х нормальных форм(НФ). Любая нормальная БД должна опираться на 3-ю НФ, ибо дальше в процессе работы/модифицирования приложения ты проблем со своей БД можешь получить очень много... Почитай на досуге про это.

[entermix]

В данном случае, для 1 работы может быть действительно только 1 исполнитель.

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

Answer 2

[Сергей Протько]

Грубо говоря, у вас есть люди и вакансии, занимаемые этими людьми. "сотрудники" и "работодатели" отображают связь между первой и второй сущностью.

Comments

[entermix]

То есть, 1 вариант?

[Сергей Протько]

entermix: зависит от задачи. Если у сотрудников и работодателей есть различные характеристики - то имеет смысл вынести это дело в отдельные таблицы и связать.