Это должно быть просто. Но как мне это спроектировать?

Question

У меня есть 2 вида бизнес-единиц; отдел и отдел. Подразделения должны быть одним или другим, но не могут быть обоими. Так что это достаточно просто. Иметь таблицу BusinessUnit и справочную таблицу BusinessUnitType, содержащую подразделение и отдел. Однако только подразделения могут содержать команды. Для каждого дивизиона есть одна ко многим командам. У отделов нет команд. Так что мне здесь делать? Может быть, у меня должен быть флаг в таблице BusinessUnitType с именем hasTeam? Это лучший способ организовать эти данные? Я не уверен, есть ли у этого конкретного дизайна имя.

Answer 1

Ваш случай выглядит как пример шаблона проектирования gen-spec.Gen-spec - сокращение от «обобщающая специализация» ( см. Определение ).Паттерн gen-spec знаком программистам, которые понимают наследование.Но реализация шаблона gen-spec в реляционной схеме может быть немного хитрой, и в учебниках по проектированию баз данных часто пропускают эту тему.

Эта тема уже упоминалась ранее.( См. Пример обсуждения ).

К счастью, в Интернете есть несколько хороших статей, которые объясняют только эту тему ( см. Пример статьи ).А поиск Google ( см. Пример поиска ) даст гораздо больше статей.

Answer 2

Немного сложно ответить без более широкого контекста (например, какие технологии вы используете, будь то новый проект, есть ли у вас какие-либо другие ограничения на реализацию и т. Д.).
но, вообще говоря, ясказал бы:

1. Если это новый проект, и у вас нет технологических ограничений, я бы рекомендовал использовать OR / M (я лично использую nHibernate).Вы можете легко настроить его под свои нужды, не беспокоясь о базовой БД.

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