Есть три сущности. Работники, Организации, Должности Каждый работник может работать в нескольких организациях и иметь несколько должностей. Т.е. связь организации с работником (его фио например) происходит всегда только посредством должности, которых может быть несколько. Вариант такой на уме: создаём табличку с полями id работника | id организации | id должности Но что-то подсказывает есть ещё варианты, более логичные штоли.. всё, спать..
Например так: Таблица "работники": ид работника, имя и т.д. Таблица "организации": "ид организации, название и т.д. Таблица "должности": ид должности, название и т.д. Таблица "работники организации": ид работника, ид организации. Таблица "должности работника": ид работника, ид должности. Последние две таблицы можно заменить, как ты сам написал, одной. Ещё третий вариант: изменить таблицу "работники", добавив поле "должности", содержащее список "ид должности" через запятую. Тоже можно сделать и организациями. Какой вариант выбрать - зависит от поставленной задачи. Но если брать пример приближённый к реальности, то должности обычно "принадлежат" организации, а не самодостаточны. Тоесть в таблице "должности" будет ещё поле "ид организации", а также поле "ид работника", который занимает эту должность. И такой вариант базы данных самый правильный. Тоесть работник может быть связан с несколькими должностями, которые могут относиться к разным организациям и, таким образом, работник может быть связан с несколькими организациями.
ага, так т.е. делаем бинарную связь. слегка "визуализирую", чтобы прикинуть чего происходит: организация-работник: например 1-1, 1-2 сделали принадлежность к организации id 1 двоих челов с id 1 и 2. теперь мы знаем что эти челы имеют связь к организации, осталось узнать какая у них должность: должность-работник: например 1-1, 1-3 сделали принадлежность к должности id 1 двоих челов с id 1 и 3. теперь знаем их должность. мне кажется это логичнее, потому что связывать организацию с работником без должности и с должностью без работника бинарной связью как-то странно. Лучше создать новую сущность "должности" с внешними ключами, не так ли? Это выкрутас в реляционной БД, или просто жесть. Я бы так не издевнулся даже если время на её решение ограничено поминутно)) Не согласен. "Должности" "принадлежат" не только к организации, но и к работнику абсолютно одинаково, типа это "связь связи". Работник (какой-то человек) имеет отношение к организации через должность и наоборот. В твоём данном примере типа так: Сущность "должности": id | название должности | id организации | id работника 1 манагер 1 1 2 секретарь 1 1 3 манагер 2 2 Мне тут не нравится преизбыточность данных, название должности неминуемо всё время должны дублироваться, даже если одинаковые, а это именно так, название должности не уникальные, вот если бы были таковыми, это вариант. Мне кажется лучше дублировать "ключи" а не "значения". Что будет, если к должности прибавится ещё какая-нибудь данная? И её тоже придётся беспощадно дублировать, что сделает помойку ещё больше. Так и не нашёл, как в моделе ER решается вопрос "связь связи"?
На самом деле зависит от поставленной задачи. Ну это понятно. Я имел ввиду, что должности - они принадлежат конкретной организации. Не бывает такого, что одна должность может принадлежать разным организациям, т.к. это не просто название, а ещё и какие-либо сопутствующие данные. Тарифная ставка, например. Дублируется только одно "название должности". Что же из-за этого поля делать справочник должностей? Если к должности прибавятся ещё какие-либо данные, то они будут относиться к должности организации. Скажем, тарифная ставка - она ведь не везде одинаковая ))
можно пример? Ну да, должность сама по себе не может, её "экземпляр" может. Конечно. Удобнее при добавлении выбирать из списка должностей, нежели печатать. Ещё потому что исключается возможность ошибки в написании должности. Порой это может быть очень важным. К примеру, генерируешь договор и отправляешь где написано в лице "Гениального директора" а не "Генерального директора" - это пример в лучшей её формулировке, может быть и хуже)) Да даже если проект не большой, такой "справочник должностей" как ты говоришь, просто удобнее. Да, это решается просто той таблицей с полями id работника | id организации | id должности можно доп.колонку сделать тарифная ставка ещё там дату вступления на должность, дату увольнения и пр. не проблема. Скажите как в модели ER решается вопрос "связь связи"? Или никак, это просто отдельная сущность и всё как в моём примере?