Решить проблему «многие к одному», дочерний элемент перед родительской таблицей - PullRequest
0 голосов
/ 17 июля 2011

В моей программе мне нужно составить организационную схему, начиная с отдельных лиц и группируя их под руководством менеджера, затем группируя этих менеджеров под старшими менеджерами и т. Д. Как мне сделать это в отношении базы данных ?? Это отношение «один к одному», которое я считал незаконным и невозможным, и все равно что начинать с дочерней таблицы - отдельных лиц - до создания ее родительского менеджера. Если кто-то может помочь мне правильно составить базу данных, я очень ценю это!

---- EDIT ---- Вот более подробное объяснение моей проблемы:

Допустим, пользователь моей программы начинает с ввода 35 человек, которых он хотел бы использовать в каком-то проекте, над которым он будет работать. Теперь есть несколько возможных руководящих должностей, которые могут быть созданы и назначены сотрудникам / другим (более низким) руководителям. Пользователь не ДОЛЖЕН создавать какую-либо конкретную позицию, но может выбирать и назначать, как ему нравится. Единственным ограничением является то, что всегда будет топ-менеджер - давайте назовем его президентом - и что он ДОЛЖЕН (но НЕ ДОЛЖЕН) назначать только 5-10 человек для любого данного менеджера (включая президента). Итак, в этом примере мы начинаем с 35 человек и президента. Теперь мы начинаем группировать 35 человек в команды и назначать одного из них в качестве менеджера. Скажем, пользователь решает иметь две команды по 6 человек, две команды по 9 человек и одну команду из 5 человек - в каждой из этих групп есть один из отдельных членов, назначенный руководителем этой команды. Итак, теперь у нас есть 5 команд, каждая под своим менеджером, и эти пять менеджеров теперь будут назначены Президентом. Программа позволила бы этому уйти, но предупредила бы пользователя, что количество людей под руководством менеджера в последней команде меньше 5 (всего 4). Таким образом, пользователь теперь может (или в ЛЮБОЕ время) вернуться и изменить организацию. Допустим, он хочет решить эту проблему и изменить команду. Таким образом, он разбивает одну из двух команд из 9 и назначает одного человека в команду, которая была коротким человеком. Это делает окончательный подсчет 3 команд из 6 (5 отдельных членов и один менеджер), одна команда из 9 (8 ind и 1 mngr), и одна команда из 8 (7 ind и 1 mngr) и все 5 руководителей команд назначены президенту.

Только в реальной жизни это может сломаться гораздо дальше - гнезда с гораздо большим количеством уровней управления. Как я могу это сделать?

Ответ Джо Хопфгартнера, приведенный ниже, все еще действителен? Могу ли я просто сделать столбец «роль», даже если роль будет назначена позже (после того, как строка будет создана)? Или поменял в любое время? Может ли этот ссылочный внешний ключ быть нулевым? (как это было бы в случае, если менеджер еще не был назначен) Или я должен переместить людей в отдельную таблицу «команда» после того, как они были назначены в команду, и переместить менеджеров в таблицу «менеджер», как только они назначен менеджером, а затем добавить внешний ключ для таблицы группы, ссылающейся на таблицу менеджера?

Кроме того, я использую MySQL, поэтому тот факт, что вы не можете использовать самоссылочные операции ON UPDATE CASCADE или ON UPDATE SET NULL, влияет на мой конкретный случай (поскольку пользователи, несомненно, будут часто изменять назначения)?

Большое спасибо за помощь в этом !!!

Ответы [ 2 ]

1 голос
/ 17 июля 2011

если один человек может иметь только одного менеджера, просто введите поле идентификатора "родительское лицо" или поместите менеджеров в отдельную таблицу.

, если нет, создайте другую таблицу для отношения, подобного "person_has_manager", который назначаетчеловек к менеджеру.

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

Чтобы решить эту проблему, вы можете ввести таблицу «person_is_manager», которая связывает человека с его работой в качестве менеджера, и лица могут быть связаны для управления этим менеджером.это может выглядеть так:

persons
-> person_id (primary)
-> name
-> etc

managers
-> person_id (primary, linked to person_id in persons)

person_has_manager
-> person_id (primary)
-> manager_id (primary, linked to person_id in managers table)
1 голос
/ 17 июля 2011

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

...