LINUX.ORG.RU

теоретический вопрос по проектированию базы данных.

 ,


0

1

Подскажите пожалуйста. Есть: Сотрудник(Имя, Отдел, Начальник_отдела).

Не могу определиться со схемой.

Придумал такой вариант.

Таблица Employees. Поля: ID(ключ), NAME, ID_departament. Таблица Departaments. Поля: ID(ключ), NAME, ID_employee(начальник).

Т. е. получается, что таблицы связаны дважды
Employess(id_departament) -> Departaments(ID)
Departaments(ID_employee) -> Employess(ID)

Но,что-то терзают меня смутные сомнения. Смущает двойная связь таблиц.
Мерещится идея убрать у сотрудника ID_departament и создать третью таблицу в которой первое поле ID сотрудника и первичный ключ, а второе ID департамента.

Проясните, пожалуйста, опытные товарищи этот момент. Имеет ли право на жизнь первое предположение или нет.

Нормальная схема. Третья таблица нужна только для many-to-many – т.е. если сотрудник может принадлежать нескольким отделам. В противном случае она только утяжелит базу – и по диску, и по скорости запросов.

А двусторонняя связь – норм. Более того, избавиться от неё невозможно в принципе, т.к. она – часть задачи. Вводя третью таблицу, ты от неё не избавляешься, а только камуфлируешь её, делая косвенной. Платя усложнением и неэффективностью за свои фантазии о том как правильно.

pr849
()
Последнее исправление: pr849 (всего исправлений: 3)

4 таблицы: 3 справочника и одна, собственно, для связи.

Anoxemian ★★★★★
()

Employess(id_departament) -> Departaments(ID)

Если сотрудник одновременно может находится только в одном отделе то этого достаточно.

urxvt ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.