Оптимальный способ хранить в MySQL доступные даты за несколько лет

Question

Мы разрабатываем базу данных MySQL (с веб-интерфейсом и внутренним интерфейсом) с праздничными пакетами. У нас все продумано, кроме лучшего метода для хранения дат отправления туристических пакетов .

Некоторые пакеты доступны почти каждый день года; другие доступны только по вторникам и средам; другие уезжают каждый понедельник с мая по сентябрь; другие пакеты отправляются только на несколько конкретных дат в течение года; и т. д. ...

Нам нужно связать каждый тур с соответствующими датами отъезда. Затем нам нужно выполнить запросы типа "дай мне те пакеты, которые доступны на дату X", "дай мне пакеты, которые я могу взять в первую неделю января", "дай мне эти туры между датой X и Y "и т. д.

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

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

Большое спасибо!

Ramon

Answer 1

Поскольку вам нужно выполнять запросы, которые ищут точные даты, я думаю, вам нужно хранить точные даты.Текстовая информация («по понедельникам», «Зимние четверги и пятницы» ...) также должна храниться, но только в информационных целях (например, для отображения на странице информации о туре).

Что касаетсядаты, у вас есть два варианта:

1) Отдельные даты

tour_id date
======= ==========
      1 2010-12-01
      1 2010-12-02
      1 2010-12-05
      2 2010-01-15

2) Диапазоны дат:

tour_id from_date  to_date
======= ========== ==========
      1 2010-12-01 2010-12-05
      2 2010-01-15 2010-01-15

Я предполагаю, что № 1 будет легче поддерживать.

Answer 2

Вот мой предложенный формат.

Храните даты доступности в отдельной таблице в виде интервалов (Дата начала, Дата окончания). Предложение будет иметь один или несколько интервалов. Для каждого из этих интервалов задайте 7-битный фильтр ограничения для доступных дней недели (по умолчанию все биты установлены в 1). Если вам нужна только одна дата, вы должны указать Start = End. Конечно, эта модель не охватывает все случаи, но мне она кажется достаточной, и она может оказаться полезной, если у вас их много, если предложения действуют только в определенные дни недели.

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

Примеры:

id | start | end | week_days
1 | 2011-01-01 | 2011-03-31 | 1111100 - The offer is available in any weekday from January to March
2 | 2011-01-31 | 2011-01-31 | 1111111 - An offer available just in one day

Если вы хотите использовать исключения, вы можете аннулировать предложение № 1 на дату добавления предложения № 2:

id | id_period | date
1 | 1 | 2011-01-31

Answer 3

Будете ли вы делать что-то кроме показа дат в этой базе данных, например, бронирования?Потому что это сильно указывало бы на то, чтобы идти дальше, чем побитовое решение: наличие одной записи на дату отъезда .

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

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