Антон Горецкий, ну это надо очень постараться, чтобы получился синтаксически корректный вопрос :)
Большинство здесь присутствующих такое даже специально не напишут, не говоря уже о случайном совпадении. Скорее тупо ошибки будут сыпаться.
Inna693, строго говоря, в вашем комментарии нет логики. В чем смысл проходить мимо того, что тебя бесит? Как бы наоборот, любой человек сделает замечание. И вы сами в первую очередь. Копить стресс не очень полезно для здоровья.
Alixx, денормализация в данном случае - это просто красивое слово, чтобы прикрыть прорехи в логике.
В целом задача довольно странная, но я бы на вашем месте отталкивался от запросов, которые понадобятся при работе с этой БД. Тогда сразу станет проще и самой понять эту странную задачу, и другим объяснить.
Лично мне сейчас кажется, что как раз работа с этой таблицей будет обставляться заборами из костылей. Но я могу не видеть всей картины.
Если я правильно понял, эта ваша таблица содержит исходные цифры, из которых потом вычитаются единички при добавлении в групп в json поле? Почему выбран json, а не отдельная таблица? А если уж джейсон для сформированных групп, то почему бы тогда сказав А не сказать и Б - сделать всего одно джейсон поле, в котором и исходные данные по количеству рабочих и менеджеров, и сформированные группы. Такое key-value хранилище. И все вопросы по структуре базы данных сразу отпадут, поскольку не будет ни базы, ни структуры.
Ну у неё немного другая задача, отличная от общепринятой.
Сходу трудно въехать. И такая структура для неё избыточна.
С другой стороны как публичный ответ, для других посетителей, как раз подойдёт.
Akina, ну, у меня привычка хранить эталонный джейсон в БД, а не в коде. Тем более что в таблице с самими услугами как раз самое место.
В общем, пришли обратно к джейсону в итоге, если говорить о масштабируемости...
С другой стороны, если вдуматься, то пожалуй да, ситуация симметричная. Только по другую строну заказа: у товаров все свойства хранятся до покупки, а у услуг - после. Так что пожалуй хранение товаров можно натянуть и на хранение покупок.
Хотя к таблицам я склоняюсь только потому, что у меня заведомо будет мало услуг, не больше десятка.
А вот если бы было хотя бы в два раза больше, то, пожалуй, останется только json.
Akina, тогда если отбросить EAV и "широкую таблицу" (как ненужную, по совету NikFaraday ниже), получается выбор между json и отдельными таблицами.
Первый вариант привлекателен тем, что при добавлении новой услуги мы не меняем структуру БД. Но вообще это лукавство - формально не меняем, а по факту это просто та часть структуры, за которую отвечаем мы сами, как всегда в noSQL. И где-то потом надо всю эту структуру (и её изменения) отдельно хранить.
А во втором у нас внешние ключи, все дела.
Мда, надо уже определяться. Перед тем как задать вопрос, я склонялся к широкой таблице, вчера думал остановиться на джейсоне, а сегодня уже почти уговорил себя на отдельные таблицы :)))
