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

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

Например:

У предприятия А следующие часы работы

• Понедельник: 9.00 - 17.00
• Вторник: 9.00 - 17.00
• Среда: 9.00 - 17.00
• Четверг: 9.00 - 17.00
• Пятница: 9.00 - 17.00
• Суббота: 9.00 - 12.00
• Воскресенье: выходной

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

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

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

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

В общем, ничего плохого в этом не вижу. Кроме...

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

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

Думаю, я бы сделал:

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 «рабочих часов». ( По крайней мере, потому что Джон Скит прав, вам могут потребоваться праздничные часы.) Хотя вы можете ослабить это ограничение, просто отказавшись от «рабочих часов» в те дни, когда предприятие закрыто.

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

Может быть, кассы театра открыты на утренник и вечерний спектакль.

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

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

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

Некоторые варианты включают;

• Схема, как у вас, но с возможностью иметь несколько периодов в один и тот же день. Он будет обслуживать перерыв на обед, но сделает неудобным выполнение запроса, который дает вам часы работы в данный день, скажем, для презентации пользователю.
• Подход в стиле растрового изображения; «000000000111111110000000» для 9-5. Обратной стороной этого подхода является то, что вам нужно выбрать конкретную степень детализации, то есть целые часы, полчаса или, действительно, минуты. Чем мельче детализация, тем труднее читать данные человеку. Вы можете использовать побитовые операторы, чтобы сохранить это значение как одно число, а не как строку целых чисел, но это опять же ухудшает читаемость.

Я узнал, что если вы хотите, чтобы разметка данных 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

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

Временной диапазон имеет формат: чч: мм-чч: мм.

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

Исходя из моего опыта, я бы порекомендовал вам разрешать несколько раз в течение дня, чтобы можно было определить, закрыты ли они в этот день явно или открыты 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;
}

Большинство результатов работает нормально для данного сценария, но он не будет столь же эффективным, если у вас есть периоды, длящиеся несколько дней, например. 8:00 ~ 2:00, тогда я рекомендую использовать многопериодный дизайн.

   0: [
         id: 1,
         business_id: 1,
         open: true,
         day: 1,
         periods: [
             0: { open: 08:00, close: 23:59 }
         ]
      ],
   1: [
         id: 2,
         business_id: 1,
         open: true,
         day: 2,
         periods: [
             0: { open: 00:00, close: 02:00 }
             1: { open: 08:00, close: 23:59 }
         ]
      ]

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