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