Блог

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

Я хочу сохранить значения, подобные следующим (пример из календаря Google), в базе данных:

Каков наилучший способ сделать это? Будет ли это одно поле базы данных или несколько?

Если первое, не соответствует ли это правилам нормализации?

Спасибо!

Я предлагаю вам создать отношение много-много, вы можете достичь этого, разделяя столбцы более логичным способом (нормализация)… для примера выше:

У вас должна быть таблица с названием «расписания» (или что-то еще, что имеет смысл для вас), другая что-то вроде «repeat_on» и третья таблица с названием «дни» (здесь у вас есть понедельник-воскресенье с их идентификаторами). В средней таблице (repeat_on) вы должны создать внешние ключи (для двух других таблиц: schedule_id и day_id), чтобы сотворить волшебство.

Таким образом, вы можете комбинировать все, что захотите, например:

 schedule    day
 1           1
 1           3
 1           7
  

Это означает, что вы должны сделать то же самое в понедельник, среду и воскресенье.

ИМО, нормализация — это искусство. Однако я обычно беру поля, подобные вашему примеру, и сохраняю их в одной таблице, поскольку у нас никогда не будет больше 7 дней. Однако, если есть хоть какой-то шанс на рост, я бы поместил его в отдельную таблицу.

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

Если можно выбрать более одного параметра, у вас должно быть по одному полю для каждого параметра со значениями ‘y’ и ‘n’ (или ‘t’ / ‘f’ для true / false). Опять же, вы должны добавить ограничение, разрешающее только эти значения. Если ваша СУБД поддерживает это, используйте битовый тип данных, который допускает только 1 и 0.

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

http://martinfowler.com/apsupp/recurring.pdf

Я знаю, что это косвенный ответ, но прочитать не помешает.

Что-то вроде дней недели — это сложно. Пачинсв и Дастин Лейн оба делают хорошие замечания. Если у вас есть список вещей на выбор, наличие таблицы кодов для перечисления вещей и таблицы пересечений, чтобы указать, какие из них выбраны, является хорошим базовым дизайном.

Сложность дней недели заключается в том, что домен (т. Е. Список дней) довольно мал, и домен никогда не будет расширяться. Кроме того, одно из преимуществ подхода с использованием таблицы пересечений заключается в том, что вы можете запускать запрос ко всему, что происходит в среду (например). Это здорово, когда ваша таблица кода представляет собой что-то вроде тегов категорий для статей блога, поскольку запрос на просмотр всего с тегом «How-To» является разумным вопросом. В случае повторения дней недели имеет ли какой-либо реальный деловой смысл говорить «покажите мне все, что повторяется по средам»? Я так не думаю. Вы наверняка будете запрашивать даты и диапазоны дат, но не дни недели и только в контексте повторяемости? Я не могу придумать практической причины для этого.

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