Comments 6
Для начала вспомним известную истину: Всё, что не указано явно, может быть как угодно.
С учётом этого постулата описанная Исходная типовая задача на самом деле не описана даже наполовину.
После внимательного изучения приведённого типового решения и сравнения его с теми ограничениями, что имеются в задаче, можно дальше не читать - решение в общем случае заведомо ошибочное, и применимо лишь к частным случаям, когда в задаче на самом деле присутствует большая куча дополнительных условий и ограничений, в текущей формулировке задачи отсутствующих.
В общем случае - должна существовать связующая таблица, связывающая группу и роль, флаг единственности должен быть атрибутом именно этой сущности "роль в группе", а уже юзеры должны линковаться на эту сущность - через ещё одну связующую таблицу.
Вы правы, если признак единственности роли в группе не является свойством роли и устанавливается на основе других бизнес правил, эту связь необходимо вынести в отдельную таблицу. Для максимально упрощенного примера в статье это будет излишним.
В том и проблема, что это не решение задачки в лабораторной работе, а статья (осмелюсь предположить, что она задумана как обучающая статья). А потому частичное формулирование задачи, а потом решение только одной из её вариаций (причём даже в решении все дополнительные ограничения не описаны - я уж не говорю о пояснениях, как изменится решение, если этот набор дополнительных ограничений изменится) - явно некорректный подход.
Модельная задача описана полностью и рассмотрены варианты решения.
Какие дополнительные условия вы хотели бы предложить включить?
Первый, и самый главный вопрос - группы абсолютно однородны? Например, если в одной группе некая роль должна присутствовать в единственном экземпляре, то означает ли это, что эта же роль в любой другой группе также должна присутствовать в единственном экземпляре?
Второй вопрос - может ли один и тот же пользователь входить в группу несколько раз с разными ролями?
Даже ответов на эти два вопроса в вариантах ДА-НЕТ вполне достаточно, чтобы породить четыре совершенно разные схемы с совершенно разной реализацией на уровне SQL - причём каждая из этих схем имеет вполне реальные практические воплощения.
В модельной задаче, которая специально упрощена, чтобы не перегружать ее и сконцентрироваться на особенностях решения с дублироваеием данных, эти вопросы не существенны.
По вопросу N1 - явно указана зависимость от роли, зависимости от группы нет в описании и для демонстрации подхода нет необходимости её добавлять. По вопросу N2 - такое ограничение не указано и уточнение наоичия/отсутствия ограничения не поможет.
В реальных задачах перечень вопросов, которые должны быть проработаны до реализации, может быть очень широким и предложенные вами вопросы конечно должны входить в этот список.
Дублирование данных для создания ограничений (контролей) на уровне БД