Пользователи и рабочий график: как хранить?

Question

[Александр Соболев]

Здравствуйте!
Есть некоторое количество пользователей: Массив U (user)
Есть рабочий график массив дат D (date) c различными состояниями T (type): Рабочий день, Выходной, Больничный, Отгул и т.д.

Муки мозга уже вторые сутки.. в каком виде лучше хранить этот массив в бд..

[user_id][date] =[type]
[user_id][date_type] = {date, date2..date N}
[date] =[ [user:type],[user2:type].. ]

чтобы максимально просто делать выборки по датам и состояниям для пользователей ?
От чего лучше отталкиваться ?

Answer 1

[Adamos]

[user_id, date, type, INDEX(user_id), INDEX(date), UNIQUE(iser_id, date)]

Comments

[Rsa97]

Лучше PRIMARY KEY (`user_id`, `date`).
И отдельный индекс по `user_id` не нужен, будет работать префикс составного индекса.

[Adamos]

Rsa97, конкретная БД не указана.

Answer 2

[Akina]

в каком виде лучше хранить этот массив в бд..

Налицо тривиальная связь типа "много-ко-много". И соответственно хранение - две таблицы связываемых сущностей и связующая таблица. Т.е.

1) User (user_id, name, ...);
2) Dates (date, type, ...);
3) UsersDates (user_id references User (user_id), date references Dates (date));

Comments

[Adamos]

А смысл дробить эту инфу на две таблицы? Чтобы практически при любом запросе джойнить?
Если уж мудрить, так наоборот - привести дату с типом к одному значению вроде 2021083103, храня в последних двух цифрах код типа дня. Возможности сравнения и выборки сохранятся... но это тоже скорее фантазия, чем реальное предложение.

[Akina]

Adamos, Вы покажите полностью предлагаемую структуру, а то по частичному описанию фрагмента трудно понять, что Вы имеете в виду.

А смысл дробить эту инфу на две таблицы? Чтобы практически при любом запросе джойнить?

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

[Adamos]

Akina, насчет полностью - это вы ТС-а спрашиваете. Я, собственно, по собственному опыту хранения рабочих графиков отписываюсь.
Имхо, нормальнее плоской таблицы юзер-дата-тип просто некуда.
Выделение дат с типами куда-то отдельно от юзеров просто не имеет смысла, они отдельно никому не понадобятся.

[Akina]

Adamos,

Имхо, нормальнее плоской таблицы юзер-дата-тип просто некуда.

Плоская таблица, например, запросто допускает рассогласование данных. Скажем, одна и та же дата у одного клиента помечена типом "Выходной", у другого- "Праздничный". И такого рода ошибка в принципе не ловится штатными подсистемами контроля целостности и противоречивости. А рукописная процедура сверки (ещё вопрос, как часто её проводить... и как определять, какой из двух вариантов корректен...) будет весьма и весьма тяжёлой...

Опять же - одна плоская таблица будет по объёму куда как пухлее, чем нормализованная структура из трёх таблиц. И, уж поверьте на слово, запросы к ней будут медленнее.

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

А вот это заведомо неверно. Календарь (соответствие дата-тип) мало того что нужно будет вводить в БД. так его ещё может потребоваться и посмотреть. Или посчитать количество праздничных дней в заданном периоде. Или ещё что...

[Adamos]

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

[Akina]

Adamos,

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

Тогда поле type должно быть не в Dates, а в UsersDates. А скорее всего и там, и там, с приоритетом частного значения.

Такие данные отрывать от работника бессмысленно.

Да, но и от даты эти данные отрывать не менее бессмысленно.

[Adamos]

Akina, если вся информация уже в UserDates, таблица Dates просто теряет смысл.

[Akina]

Adamos, таблица календаря (эталонный календарь без индивидуальных данных) - она не просто имеет смысл, она обязательна. Особенно с учётом необходимости заполнения для будущих периодов. Кроме того, могут существовать данные, связанные именно с датой, а не с комплектом дата+юзер.

[Adamos]

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

[Akina]

Adamos,

Только с этими данными она будет связана очень косвенно.

Это типичное отношение pattern-entity. И связь самая прямая - COALECSE(usersdates.type, dates.type).

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

Это никак не мешает формированию индивидуального графика для сотрудника на отсутствующий в паттерне период.

[Adamos]

Akina, брэк. Будем считать архитектуру этого воздушного замка предварительно обсужденной ;)

[Akina]

Adamos, принимается. Правда, мне сквозь вакуум привиделся конь, шарообразный такой.