Как лучше всего хранить данные о группах в бд?

Question

[Alixx]

Здравствуйте.
Проектирую бд под следующую задачу.
У каждого пользователя есть рабочие и управляющие, из них нужно формировать группы и направлять их на работу.
Каждый рабочий имеет разную производительность от 1 до 5. Управляющие все одинаковы и равноценны.
Они все безликие. Нету даже имени. Поэтому нет смысла делать запись для каждого рабочего и каждого управляющего.
У пользователя указывается кол-во рабочих каждого уровня производительности и кол-во управляющих.

Группы нужно формировать из 1 управляющего и из 1-3 рабочих.
На одну работу можно назначить несколько групп.

После запуска работы и до её завершения, группы участвующие в этой работе не могут быть расформированы.
Как только работа завершается, группы становятся свободными и их можно переформировать или распустить.

Считаю, что хранить данные о каждой группе в отдельной записи в таблице нецелесообразно, т.к. группы как расходный ресурс будут - то формируются, то расформировываются.
Но при этом нужно хранить составы работающих и свободных групп.
----
Пока что остановилась на таком варианте:

Таблица groups:
id_user,
managers,
workers_1,
workers_2,
workers_3,
workers_4,
workers_5,
formed_groups.

И ещё есть таблица jobs с данными о запущенных работах.
Всё типа int, кроме formed_groups - у него тип json.
В formed_groups хранятся списки сформированных групп. Для работающих ещё указывается id соответствующей работы из jobs.
Ну а в таблице работ jobs не будет информации о работающих группах.

----
Рассматриваю ещё такой вариант:
Всё почти то же самое, что в первом варианте. Только теперь в groups->formed_groups храним данные о свободных группах. А данные о работающих группах храним в jobs, также в json.

Возникает вопрос, как лучше всего хранить эти данные в бд? В приоритете производительность.

Comments

[Дмитрий]

На взгляд управляющий не нужен, так как юзер может и быть им. Его номер

[d'Ivan]

workers_1,
workers_2,
workers_3,
workers_4,
workers_5,

а если хорошо подумать?

[Alixx]

Дмитрий, вы не так поняли. У каждого юзера есть по несколько управляющих и рабочих. Юзер формирует группы для своих работ. Кол-во управляющих у юзера может менять со временем. Поэтому, может возникнуть ситуация, когда управляющих не хватит на все группы из 3х рабочих.
Everything_is_not_so_bad, в один workers типа json записывать?

[Виктор]

Мне кажется здесь есть непонимание нормальных форм

[Ипатьев]

Распечатайте, пожалуйста, на листе бумаги А4 и повесьте перед собой на стенку:

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

после этого сделайте таблицу worker_groups с полями group и worker и добавьте в неё всех этих workers_х, каждого на своей строчке

[Alixx]

Ипатьев, Спасибо за совет, только в конце надо заменить на "вы делаете денормализацию".
workers_х хранят кол-во рабочих каждого уровня производительности (что x и обозначает), которые принадлежат пользователю.
Зачем их переносить в worker_groups и записывать вместе с group, я, извините, не поняла. Можно подробней узнать вашу идею?

[alexalexes]

Alixx, если добавите worker_6, то будете переписывать все запросы, вместо того, чтобы просто добавить строчку в worker_groups?

[Виктор]

Alixx,

вы делаете денормализацию

Даже для денормализации делать колонки worker_x не нормально) тогда уж json.

Только сколько у Вас RPS? Зачем Вам денормализация?

[Ипатьев]

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

В целом задача довольно странная, но я бы на вашем месте отталкивался от запросов, которые понадобятся при работе с этой БД. Тогда сразу станет проще и самой понять эту странную задачу, и другим объяснить.
Лично мне сейчас кажется, что как раз работа с этой таблицей будет обставляться заборами из костылей. Но я могу не видеть всей картины.

Если я правильно понял, эта ваша таблица содержит исходные цифры, из которых потом вычитаются единички при добавлении в групп в json поле? Почему выбран json, а не отдельная таблица? А если уж джейсон для сформированных групп, то почему бы тогда сказав А не сказать и Б - сделать всего одно джейсон поле, в котором и исходные данные по количеству рабочих и менеджеров, и сформированные группы. Такое key-value хранилище. И все вопросы по структуре базы данных сразу отпадут, поскольку не будет ни базы, ни структуры.

[Alixx]

Спасибо за отклики.
Да, я не расписывала все подводные камни, но благодаря всем вашим обсуждениям я пришла к схеме, решающей мою задачу. Так что спасибо всем за помощь.

Answer 1

[Alixx]

Мне подошла такая схема:

groups
    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_groups_sets
    id_user: foreign key -> users.id (primary key)
    managers_count: int // кол-во всех управляющих
    workers_1_count: int // кол-во всех рабочих 1 уровня производительности и т.д.
    workers_2_count: int
    workers_3_count: int
    workers_4_count: int
    workers_5_count: int

Т.к. группа не может быть сформирована без управляющего, то id управляющего можно сделать идентификатором бригады. А в группе надо знать, какого уровня рабочие там собраны, вот и указываем (для 3х возможных мест рабочих) уровни рабочие, которые были сформированы в группу.
Свободные группы - те, в которых work_id is null и хотя бы один из worker_X_rarity is not null.
Работающие группы - где work_id is not null.
Свободные управляющие - где все worker_X_rarity is null.

В интерфейсе для формирования групп надо получать данные о всех группах, управляющих и рабочих. Поэтому тут два запроса всего - из groups и users_groups_sets получить все записи по id пользователя. На уровне приложения уже формируем все данные: о свободных и работающих группах, о свободных управляющих и рабочих.

Удалять прямо из сформированной группы нельзя ни рабочих, ни управляющего.
Когда рабочего добавляем юзеру, то добавляем 1 к workers_X_count, где X - это уровень производительности этого рабочего.
Когда удаляем, то отнимаем 1 от нужного workers_X_count.
С добавлением управляющего, также +1 и, если есть запись с is_deleted == true, то просто у неё ставим false, иначе создаём запись в groups.
Когда удаляем, то также -1, а в groups у первой найденной записи, где все worker_X_rarity is null, ставим is_deleted в true.

Comments

[Ипатьев]

Вы или отредактируйте заголовок вопроса, или снимите отметку "решение". потому что ваш вырожденный случай ничего общего не имеет с хранением групп, нужным нормальным людям. Которые будут попадать сюда из поиска.

Answer 2

[Saboteur]

table resources
user_name, user_id, w1_total, w1_used, w2_total, w2_used, w3_total, w3_used, w4_total, w4_used, w5_total, w5_used

table groups
user_id, group_name, w1,w2,w3,w4,w5, current_task

Answer 3

[Nik Faraday]

Вот такой вариант есть

task
    id:guid unique

groups
    id:guid unique
    task_fk:guid <--

manager:
    id:guid unique
    group_fk:guid unique

worker
    id:guid unique
    group_fk:guid <--

Обратите внимание на строку, где указана стрелочка. Отсутствие ключевого слова unique даёт возможность нескольким записям в этой таблице быть связанным с другой таблицей (groups) либо, другими словами, связь one-to-many. Наличие unique в таблице managers явно указывает, что только один менеджер может быть привязан в конкретной группе, другими словами, это связь one-to-one, где внешний ключ (foreign key) находится в таблице managers.

Группы нужно формировать из 1 управляющего и из 1-3 рабочих.

Это уже часть бизнес-логики, это не имеет отношения к проектирования БД

Comments

[Ипатьев]

Ну у неё немного другая задача, отличная от общепринятой.
Сходу трудно въехать. И такая структура для неё избыточна.
С другой стороны как публичный ответ, для других посетителей, как раз подойдёт.

[Nik Faraday]

Ипатьев,

Сходу трудно въехать

Да, есть такое. Скорее всего, не до конца понял. Нужно будет пересмотреть

[Alixx]

Спасибо за ответ. Но это очевидная схема и, как верно уже подметили, она даже избыточна, т.к.

Управляющие все одинаковы и равноценны. Они все безликие. Нету даже имени. Поэтому нет смысла делать запись для каждого рабочего и каждого управляющего.

Я по итогу пришла к такой схеме:

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

[Nik Faraday]

Alixx, ваша схема не имеет смысла, она не достоверна с точки зрения проектирования и вызовет у вас проблемы в будущем

Вам и так, и так нужно хранить где-то и воркеров, а менеджеров, даже если они безликие и имени у них нет. Потому что будут проблемы при разработке.

У вас ещё может быть вариант хранить просто worker_types в отдельной таблице в pk названием типа работника и, возможно, номер типа.

Или я могу ошибаться, я ведь не знаю вашего проекта. Но на больших рабочих проектах это недопустимо

[Alixx]

Nik Faraday, Да, я не расписывала все подводные камни, но благодаря всем обсуждениям тут я пришла к схеме, решающей мою задачу. Так что спасибо и вам за помощь.

[Nik Faraday]

Alixx, так хоть ответ напишите )