Хранение рабочих часов в базе данных

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

Например:

Бизнес A имеет следующие часы работы

Понедельник: 9:00 - 17:00
Вторник: с 9:00 до 17:00
Среда: 9:00 - 17:00
Четверг: 9:00 - 17:00
Пятница: с 9:00 до 17:00
Суббота: 9:00 - 12 полдень
Воскресенье: Закрыто

В настоящее время у меня есть модель данных, аналогичная следующей

CREATE TABLE "business_hours" (
    "id" integer NOT NULL PRIMARY KEY,
    "day" varchar(16) NOT NULL,
    "open_time" time,
    "close_time" time
)

где "день" ограничен выбором семи дней недели в коде (через ORM). Чтобы проверить, закрыт ли бизнес на определенный день, он проверяет, являются ли open_time и close_time NULL. Это связано с бизнесом через промежуточную таблицу (отношение многих к многим).

Есть ли у кого-нибудь предложения по этой схеме базы данных? Что-то в этом не похоже на меня.

Ответ 1

В целом, я не вижу ничего плохого в этом. За исключением...

Я бы сохранил день недели как целое число, используя любую систему нумерации, используемую вашим родным языком программирования (в ее библиотеках). Это уменьшит размер базы данных и удалит сравнения строк с вашим кодом.
Я бы, вероятно, поместил внешний ключ в бизнес-таблицу прямо здесь, в этой таблице. Таким образом вам не понадобится таблица ссылок.

Итак, я бы сделал:

CREATE TABLE "business_hours" (
     "id" integer NOT NULL PRIMARY KEY,
     "business_id" integer NOT NULL FOREIGN KEY REFERENCES "businesses",
     "day" integer NOT NULL,
     "open_time" time,
     "close_time" time
)

В моей бизнес-логике я принуждаю к ограничению, что каждый "бизнес" имеет не менее 7 рабочих часов ". (По крайней мере, потому, что Джон Скит прав, вы можете захотеть праздничных часов.) Хотя вы можете расслабиться от этого ограничения, просто оставив" рабочее время" в течение нескольких дней, когда бизнес закрыт.

Ответ 2

Одна из ситуаций, не охваченных этой схемой, - это несколько периодов открытия за один день. Например, локальный паб открыт 12: 00-14: 30 и 17: 00-23: 00.

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

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

Как насчет времени открытия, которое пересекает полночь. Скажем, бар открыт с 19:00 до 02:00. Вы не могли просто сравнить время открытия и закрытия со временем, которое вы хотите проверить.

Ответ 3

Это зависит от того, что вам нужно для хранения и для чего могут выглядеть данные в реальном мире.
Если вам нужно определить, открыт ли бизнес в определенный момент, то может быть немного неудобно запрашивать схему, как указано. Что еще более важно, однако, есть: вам когда-нибудь понадобится обеспечить закрытие в середине дня?

Некоторые параметры включают;

Схема, подобная той, что у вас есть, но с возможностью иметь несколько периодов за тот же день. Это послужило бы для обеденного перерыва, но было бы неудобно запускать запрос, который дает вам часы работы в течение определенного дня, например, для представления пользователю.
Подход в стиле растрового изображения; "000000000111111110000000" для 9-5. Недостатком этого подхода является то, что вам нужно выбрать конкретную детализацию, т.е. Целые часы или полчаса или, действительно, минуты. Чем мельче гранулярность, тем труднее данные читать для человека. Вы можете использовать побитовые операторы, чтобы сохранить это значение как одно число, а не целую цепочку, но опять-таки ущемляет удобочитаемость.

Ответ 4

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

https://schema.org/openingHours

http://schema.org/OpeningHoursSpecification Содержит "действительные даты", что очень полезно для некоторых компаний.

https://schema.org/docs/search_results.html#q=hours

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

В одном из моих проектов я использовал столбцы:

[uInt] business_id, [uTinyInt] день, [ char (11)] timeRange

Если вы хотите поддерживать функцию OpenHoursSpecification, вам нужно добавить validFrom и validThrough.

Временной диапазон отформатирован так: hh: mm-hh: mm

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

Из моего опыта я бы рекомендовал вам разрешить несколько раз в течение дня, дать возможность узнать, закрыты ли они в тот же день или открыт 24 часа или 24/7. У меня было мое мнение, что если в БД был день, то в тот день бизнес был закрыт.

/**
 * parseTimeRange
 * parses a time range in the form of
 * '08:55-22:00'
 * @param $timeRange 'hh:mm-hh:mm' '08:55-22:00'
 * @return mixed ['hourStart'=>, 'minuteStart'=>, 'hourEnd'=>, 'minuteEnd'=>]
 */
function parseTimeRange($timeRange)
{
    // no validating just parsing
    preg_match('/(?P<hourStart>\d{1,2}):(?P<minuteStart>\d{2})-(?P<hourEnd>\d{1,2}):(?P<minuteEnd>\d{2})/', $timeRange, $matches);

    return $matches;
}

Ответ 5

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