У этой задачи глобальных проблемы две: сотрудники; подразделения. Решение на самом деле в разных случаях индивидуальное, и нужно отталкиваться от наиболее полного видения системы года через 2-3 именно в части этих справочников

ага, это причина проблем в скраме - отсутствие достаточных знаний о будущем развитии, что в какой-то момент приводит к постоянной переделке фундамента системы - модели данных

Если бы это была проблема именно скрама, универсальное решение этой задачки дали бы лет 40 назад)

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

вы пока не рассказали бизнес-задачу

ещё можно в EAV всё хранить

модель данных проблемный фундамент, только если у вас нет нормальной изоляции бизнес-логики

Есть хорошее правило при проектировании, когда отсутствуют достаточные знания о будущем развитии системы: проектировать систему и её сущности как можно менее связно. Просто вводим необходимые сущности и их характеристики (полнота характеристик - в зависимости от текущих нужд системы и решаемых задач). И отдельные слои (таблицы) бизнес логики,  которые связывают сущности в таком ключе, который необходим на текущем этапе развития системы. При понимании, что текущий слой бизнес логики исчерпал свой потанцеал (структура устарела и тп),  проектируем новый слой и процесс переноса логики ver.1 в новую ver.2

связывающие таблицы являются логикой, надо делить логику на атомарную, что увеличит количество связей, но дает гибкость в изменении этой бизнес логики

то есть FK в таблице сущность это внедрение логики в сущность, а изоляция - как раз вынос это логики в связывающую таблицу, то есть как вы сказали - изоляция логики

при наследовании средствами ordbms, как по ссылке выше, FK не нужен

я так и не понял, в чем проблема с пустым FK customer_id

Всем доброго времени суток! Работаю сейчас над курсовой работой, по теме модернизация образовательных учреждений. В рамках работы внедряю видеоконференцсвязь, систему машинного зрения с контролем посещаемости и внимания на семинарах и систему контроля экзаменуемых.  Сейчас собираю материал для описания архитектуры типового университета и бизнес-процессов как они есть на данный момент. Может у кого-нибудь есть материал на эту тему, источники или рабочие инсайты, буду очень рад если поделитесь) заранее  спасибо! 😊

у меня есть рабочий инсайт — университеты в текущей типовой архитектуре должны умереть

Не спорю, но к сожалению за такой подход к решению мне точно не поставят хорошую оценку )))

а почему нам стоит вам помогать натягивать сову на глобус? это сообщество практиков

ваша хорошая оценка интересует нас меньше всего

расскажите, каких значимых позитивных изменений вы хотите добиться для конкретной компании, отрасли, клиентов или части общества — и мы вам поможем

система машинного зрения с целью контроля посещаемости и внимания на семинарах и контроля экзаменуемых? Егор, сорри, но это маразм. Такое работать не будет.

Отрасль - образование, в качестве клиента выступает проректор по цифровому развитию, конечный пользователь- преподавательский состав, студенты. Данные решения как продукты уже были реализованы в нескольких университетах и не только в образовательной отрасли но и в производственной компании по части аттестации в рамках повышени профессиональных навыков сотрудников