Здравствуйте.
Проектирую бд под следующую задачу.
У каждого пользователя есть рабочие и управляющие, из них нужно формировать группы и направлять их на работу.
Каждый рабочий имеет разную производительность от 1 до 5. Управляющие все одинаковы и равноценны.
Они все безликие. Нету даже имени. Поэтому нет смысла делать запись для каждого рабочего и каждого управляющего.
У пользователя указывается кол-во рабочих каждого уровня производительности и кол-во управляющих.
Группы нужно формировать из 1 управляющего и из 1-3 рабочих.
На одну работу можно назначить несколько групп.
После запуска работы и до её завершения, группы участвующие в этой работе не могут быть расформированы.
Как только работа завершается, группы становятся свободными и их можно переформировать или распустить.
Считаю, что хранить данные о каждой группе в отдельной записи в таблице нецелесообразно, т.к. группы как расходный ресурс будут - то формируются, то расформировываются.
Но при этом нужно хранить составы работающих и свободных групп.
----
Пока что остановилась на таком варианте:
И ещё есть таблица jobs с данными о запущенных работах.
Всё типа int, кроме formed_groups - у него тип json.
В formed_groups хранятся списки сформированных групп. Для работающих ещё указывается id соответствующей работы из jobs.
Ну а в таблице работ jobs не будет информации о работающих группах.
----
Рассматриваю ещё такой вариант:
Всё почти то же самое, что в первом варианте. Только теперь в groups->formed_groups храним данные о свободных группах. А данные о работающих группах храним в jobs, также в json.
Возникает вопрос, как лучше всего хранить эти данные в бд? В приоритете производительность.
Дмитрий, вы не так поняли. У каждого юзера есть по несколько управляющих и рабочих. Юзер формирует группы для своих работ. Кол-во управляющих у юзера может менять со временем. Поэтому, может возникнуть ситуация, когда управляющих не хватит на все группы из 3х рабочих. Everything_is_not_so_bad, в один workers типа json записывать?
Ипатьев, Спасибо за совет, только в конце надо заменить на "вы делаете денормализацию".
workers_х хранят кол-во рабочих каждого уровня производительности (что x и обозначает), которые принадлежат пользователю.
Зачем их переносить в worker_groups и записывать вместе с group, я, извините, не поняла. Можно подробней узнать вашу идею?
Alixx, денормализация в данном случае - это просто красивое слово, чтобы прикрыть прорехи в логике.
В целом задача довольно странная, но я бы на вашем месте отталкивался от запросов, которые понадобятся при работе с этой БД. Тогда сразу станет проще и самой понять эту странную задачу, и другим объяснить.
Лично мне сейчас кажется, что как раз работа с этой таблицей будет обставляться заборами из костылей. Но я могу не видеть всей картины.
Если я правильно понял, эта ваша таблица содержит исходные цифры, из которых потом вычитаются единички при добавлении в групп в json поле? Почему выбран json, а не отдельная таблица? А если уж джейсон для сформированных групп, то почему бы тогда сказав А не сказать и Б - сделать всего одно джейсон поле, в котором и исходные данные по количеству рабочих и менеджеров, и сформированные группы. Такое key-value хранилище. И все вопросы по структуре базы данных сразу отпадут, поскольку не будет ни базы, ни структуры.
Обратите внимание на строку, где указана стрелочка. Отсутствие ключевого слова unique даёт возможность нескольким записям в этой таблице быть связанным с другой таблицей (groups) либо, другими словами, связь one-to-many. Наличие unique в таблице managers явно указывает, что только один менеджер может быть привязан в конкретной группе, другими словами, это связь one-to-one, где внешний ключ (foreign key) находится в таблице managers.
Группы нужно формировать из 1 управляющего и из 1-3 рабочих.
Это уже часть бизнес-логики, это не имеет отношения к проектирования БД
Ну у неё немного другая задача, отличная от общепринятой.
Сходу трудно въехать. И такая структура для неё избыточна.
С другой стороны как публичный ответ, для других посетителей, как раз подойдёт.
Спасибо за ответ. Но это очевидная схема и, как верно уже подметили, она даже избыточна, т.к.
Управляющие все одинаковы и равноценны. Они все безликие. Нету даже имени. Поэтому нет смысла делать запись для каждого рабочего и каждого управляющего.
Я по итогу пришла к такой схеме:
brigades
user_id: foreign key -> users.id
manager_id: int
user_id, manager_id: primary key
is_deleted: boolean
work_id: foreign key -> works.id, nullable
worker_1_rarity: int, nullable
worker_2_rarity: int nullable
worker_3_rarity: int, nullable
users_brigades_sets
id_user: foreign key -> users.id (primary key)
managers_count: int
workers_1_count: int
workers_2_count: int
workers_3_count: int
workers_4_count: int
workers_5_count: int
Средний
Простой
