Представление рабочих часов/расписания в реляционной базе данных

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

Система должна быть в состоянии представить любую комбинацию почасовых графиков 24/7, т.е.:

  • пн 8-9, вт 1-5, ср 15-22;
  • пн-пт 13-16;
  • Сб-Вс 8:00-18:00;

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

Любой опыт/руководство/направление для этого будет высоко оценен.


person Ana Ban    schedule 10.04.2012    source источник


Ответы (2)


Я бы смоделировал это, сосредоточившись на доступности на каждый день для каждого пользователя со следующими столбцами:

а) День (1-7), где 1 — воскресенье, а 7 — суббота в соответствии с соглашениями MySQL.

b) Время начала — время начала может быть нулевым, если оно недоступно

c) Время окончания — время окончания может быть нулевым, если оно недоступно.

г) Примечания - любые примечания о доступности в этот день

e) userid (идентификатор пользователя, чье расписание отображается)

f) Недоступно - Да/Нет

Это означает, что у каждого пользователя будет 7 записей доступности. Однако на лице пользователя вы можете выполнять настройки, чтобы копировать данные из одного дня в другой.

person Stephen Senkomago Musoke    schedule 10.04.2012
comment
спасибо, @ssmusoke, работаю над этим. будет ли Day типом INT? что именно вы имеете в виду соглашения MySQL? :D - person Ana Ban; 10.04.2012
comment
Существуют разные соглашения для дня недели, но MySQL использует 1 для воскресенья и 7 для субботы, однако в некоторых языках для воскресенья используется 0, а для субботы — 6. Я рекомендую вам использовать tinyint без знака (это означает, что это может быть только + ve), который идет от 1 до 128, так как этого будет достаточно для ваших нужд. Int достигает 2 миллиардов, поэтому вам все это не нужно. - person Stephen Senkomago Musoke; 10.04.2012
comment
aaiyt, что я наконец сделал, так это добавил дополнительную таблицу Empl_Schedule, имеющую только поля Empl_ID, Empl_Day и Empl_Time - все без знака tinyint, все как составной первичный ключ. Empl_Day будет иметь значения 1,2..7 и Empl_Time 0,1..23. одна запись строки будет сделана для каждого часа любого дня, когда сотрудник доступен. наконец, в таблице Employee есть логическое поле FullTime. спасибо, @ssmusoke - person Ana Ban; 10.04.2012
comment
Один столбец для времени не учитывает 8-9 утра, 3-10 вечера и т. д., поэтому вам нужны столбцы времени начала и окончания. - person Stephen Senkomago Musoke; 10.04.2012
comment
на самом деле это возможно: если Empl_ID равен 12, пн с 8 до 9 утра, с 15 до 22 часов будет (12, 2, 8), (12, 2, 15), (12, 2, 16), (12, 2, 17), (12, 2, 18), (12, 2, 19), (12, 2, 20), (12, 2, 21) :) - person Ana Ban; 12.04.2012
comment
Вам будет сложно запросить позже, так как вам нужно свести данные, лучше понедельник 8-9, (12, 2, 8, 9), понедельник 15-22, (12, 2, 15, 22), где каждый период является автономным, и вы можете отобразить его в календаре. В вашем случае у вас может быть 7 x 24 записи для каждого сотрудника, что произойдет, если у вас 1000 сотрудников? - person Stephen Senkomago Musoke; 12.04.2012
comment
да... Меня смущает масштабирование. обязательно сработаю снова, спасибо @ssmusoke - person Ana Ban; 12.04.2012

Почему бы просто не создать ассоциацию между интервалами и пользователями за период времени? Если вы знаете, что это повторяющаяся 1 неделя, вы выбираете любую неделю. Если вы знаете, что это повторяющийся месяц, вы выбираете любой месяц и т. д.

StartAvailableDateTime1 DATETIME,
AvailableDateTime2 DATETIME,
UserID INT

person CHaisPas    schedule 10.12.2014