Каков наилучший способ хранения дней недели, когда событие происходит в реляционной базе данных?

Ответ 1

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

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

Я бы избежал поиска, потому что это было бы слишком нормальным. Если ваш набор элементов поиска не является очевидным или, возможно, может измениться, он будет излишним. В случае дней недели (в отличие от США, например), я бы спокойно спал с фиксированным набором.

Учитывая область данных, я не думаю, что бит-билд обеспечит вам значительную экономию пространства и просто сделает ваш код более сложным.

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

Ответ 2

Мне не сложно записывать запросы, если мы используем бит. Просто используйте простую двоичную математику. Я думаю, что это самый эффективный метод. Лично я делаю это все время. Посмотрите:

 sun=1, mon=2, tue=4, wed=8, thu=16, fri=32, sat=64. 

Теперь, скажем, курс проводится в понедельник, в среду и в пятницу. значение для сохранения в базе данных будет 42 (2 + 8 + 32). Затем вы можете выбрать курсы в следующую среду:

select * from courses where (days & 8) > 0

Если вы хотите, чтобы курсы на thu и fri вы писали:

select * from courses where (days & 48) > 0

Эта статья актуальна: http://en.wikipedia.org/wiki/Bitwise_operation

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

Надеюсь, что это поможет.

Ответ 3

Возможное # 4: Почему это должен быть один столбец? Вы можете добавить 7 бит столбцов для каждого дня недели в таблицу. Написание SQL против него просто, просто проверьте для 1 в столбце по вашему выбору. И чтение кода приложения из базы данных просто скрывает это в коммутаторе. Я понимаю, что это ненормальная форма, и я обычно трачу довольно много времени, пытаясь отменить такие проекты у предыдущих программистов, но я несколько сомневаюсь, что мы собираемся добавить восьмой день на неделю в ближайшее время.

Чтобы прокомментировать другие решения, я, вероятно, стонал бы, если бы столкнулся с таблицей поиска. Моим первым наклонением было также поле бит с несколькими пользовательскими функциями базы данных, которые помогут вам легко писать естественные запросы в этом поле.

Мне будет интересно прочитать некоторые другие предложения, которые приходят людям.

Изменить: я должен добавить, что # 3 и вышеприведенное предложение легче добавить индексы. Я не уверен, как можно написать SQL-запрос, например "получить все классы в четверг" для запросов №1 или №2, которые не приведут к сканированию таблицы. Но сегодня я могу быть тусклым.

Ответ 4

Решение № 3, по-видимому, ближе всего к тому, что я бы рекомендовал. Расширение идеи таблицы поиска. Каждый курс имеет одну или несколько сеансов. Создайте таблицу сеанса с атрибутами: course_id, day, time, lecturer_id, room_id и т.д.

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

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

Значение таблиц будет более четким, что упростит долгосрочное обслуживание.

Ответ 5

Если вы выберете один или два, ваша таблица не будет в 1NF (первая нормальная форма), так как она содержит многозначный столбец.

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

Ответ 6

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

Свяжите свой курс с таблицей "расписание".

Это, в свою очередь, связано с таблицей days_in_schedule.

В таблице days_in_schedule указаны столбцы имя_расписания и дата in_schedule_day. Строка для каждого действительного дня в этом расписании.

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

Вы можете справиться не только с курсом только по пятницам, но также "только в первом семестре", "лаборатория закрыта для ремонта в третьем семестре", а "канадский филиал имеет календарь расписания знакомств".

Другие возможные запросы: "Какая дата окончания 20-дневного курса, начинающегося 1 апреля", который "расписывает больше всего". Если вы действительно хорошо разбираетесь в SQL, вы можете спросить: "Какие возможные дни открыты в курсе xxx для ученика, который уже забронирован для курса yyy", - что у меня такое чувство, это настоящий кукол вашей предлагаемой системы.