Как указывают многие комментарии, обычно плохая идея кодировать все данные в строку, которая в принципе не имеет смысла для базы данных.Обычно лучше определить элементы данных и их отношения и представить эти структуры в базе данных.Статья Википедии о моделях данных является хорошим обзором того, что с ней связано (хотя она гораздо более общая, чем то, что вам нужно).Проблема, которую вы описываете, кажется достаточно простой, чтобы вы могли сделать это карандашом и бумагой.
Один из способов начать - записать списки логических связей между концепциями в вашей проблеме.Например, список может выглядеть следующим образом (ваши правила могут отличаться):
- Каждый сотрудник следует одному расписанию.
- У каждого сотрудника также есть имя и фамилияв качестве идентификатора сотрудника.Разные сотрудники могут иметь одинаковые имена, но идентификатор каждого сотрудника является уникальным для этого сотрудника.
- В расписании есть день начала и окончания недели, а также время начала и окончания дня.
- Время начала и окончания одинаково для каждого дня расписания.
- Несколько сотрудников могут быть в одном и том же расписании.
Отсюда вы можете перечислить существительные, используемые вправила.Это кандидаты для сущностей (столбцов) в базе данных:
- Сотрудник
- Идентификатор сотрудника
- Имя сотрудника
- Фамилия сотрудника
- Расписание
- День начала расписания
- Время начала расписания
- День окончания расписания
- Время окончания расписания
Для правил, которые я перечислил, графики, кажется, существуют независимо от сотрудников.Поскольку необходим способ определения того, какой график следует сотруднику, имеет смысл добавить еще одну сущность:
Если вы посмотрите на глаголыв правилах («следует», «имеет» и т. д.) вы начинаете понимать отношения.Я бы сгруппировал все до двух отношений:
Employees
ID
first_name
last_name
schedule_ID
Schedules
ID
start_day
start_time
end_day
end_time
Это все, что нужно для структур данных.(Разумной альтернативой start_day и end_day для таблицы расписаний будет логическое поле для каждого дня недели.) Следующим шагом является разработка индексов.Это обусловлено запросами, которые вы ожидаете сделать.Возможно, вы захотите посмотреть следующее:
- По какому расписанию следует сотрудник с ID = xyz?
- Кто работает по понедельникам в полдень?
- Чтодни, когда никто не работает?
Поскольку сотрудники и расписания однозначно идентифицируются по их соответствующим идентификаторам, они должны быть основными полями соответствующих таблиц.Вы также, вероятно, хотите иметь правила согласованности для данных.(Например, вы не хотите, чтобы сотрудник работал по расписанию, которое не определено.) Это можно сделать путем определения отношения «внешний ключ» между полем Employees.schedule_ID и полем Schedules.ID, что означает, что Employees.schedule_ID должно быть проиндексировано.Однако, поскольку сотрудники могут использовать одно и то же расписание, оно не должно быть уникальным индексом.
Если вам нужно просматривать расписания по дням недели и времени суток, их также стоит проиндексировать.Наконец, если вы хотите искать сотрудников по имени, эти поля, возможно, следует проиндексировать.