Как бы вы хранили и запрашивали часы работы?

сохранять каждый непрерывный блок времени как время начала и продолжительность; это упрощает проверку, когда часы пересекают границы даты

если вы уверены, что часы работы никогда не выйдут за границы даты (т. е. никогда не будет открытой ночной распродажи или 72-часового марафона и т. д.), тогда будет достаточно времени начала/окончания

Наиболее гибким решением может быть использование битового подхода. В неделе 168 часов, значит, 672 периода по 15 минут. Это всего 84 байта пространства, что должно быть терпимо.

Я бы использовал такую ​​таблицу:

BusinessID | weekDay | OpenTime | CloseTime 
---------------------------------------------
     1          1        9           13
     1          2        5           18
     1          3        5           18
     1          4        5           18
     1          5        5           18
     1          6        5           18
     1          7        5           18

Здесь у нас есть бизнес, в котором обычные часы работы с 5 до 6, но более короткие часы в воскресенье.

Запрос на открытие будет (psuedo-sql)

SELECT @isOpen = CAST
   (SELECT 1 FROM tblHours 
       WHERE BusinessId = @id AND weekDay = @Day 
       AND CONVERT(Currentime to 24 hour) IS BETWEEN(OpenTime,CloseTime)) AS BIT;

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

Не забудьте сохранить часовой пояс предприятия в отдельной таблице (нормализовать!), и выполнить преобразование между вашим временем и этим, прежде чем делать эти сравнения.

Я думаю, что лично я выбрал бы время начала + время окончания, так как это сделало бы все более гибким. Хороший вопрос: какова вероятность того, что размер блока изменится в определенный момент? Затем выберите решение, которое лучше всего подходит для вашей ситуации (если оно может измениться, я бы определенно выбрал временные промежутки).

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

Чтобы добавить к тому, что сказал Джонатан Холланд , Я бы разрешил несколько записей в один и тот же день.

Я бы также разрешил десятичное время или другой столбец для минут.

Почему? во многих ресторанах и некоторых компаниях, а также во многих компаниях по всему миру есть обеденный и/или дневной перерыв. Кроме того, многие рестораны (2 из которых я знаю рядом с моим домом) закрываются в нечетное время, отличное от 15. Один закрывается в 21:40 по воскресеньям, а другой закрывается в 1:40.

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

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

businessID  | datetime              | type
==========================================
        1     10/1/2008 10:30:00 AM    1
        1     10/1/2008 02:45:00 PM    0
        1     10/1/2008 05:15:00 PM    1
        1     10/2/2008 02:00:00 AM    0
        1     10/2/2008 10:30:00 AM    1

и т. д. (тип: 1 открытый и 0 закрытый)

И рассчитать все дни на ближайшие 1-2 года на 1-2 года вперед. Обратите внимание, что у вас будет только 3 столбца: int, дата/время/бит, поэтому потребление данных должно быть минимальным.

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

Он также заботится о пересечении полуночи, а также о преобразованиях 12/24 часов.

Он также не зависит от часового пояса. Если вы сохраняете время начала и продолжительность, когда вы вычисляете время окончания, будет ли ваша машина давать вам скорректированное время TZ? Это то, что вы хотите? Больше кода.

что касается запроса статуса открытия-закрытия: запросите соответствующую дату-время,

select top 1 type from thehours where datetimefield<=somedatetime and businessID = somebusinessid order by datetime desc

затем посмотрите на «тип». если 1 - открыто, если 0 - закрыто.

PS: я был в рознице в течение 10 лет. Так что я знаком с проблемами сумасшедших часов малого бизнеса.

Хорошо, я добавлю это, потому что оно того стоит.

Мне нужно уладить довольно много дел.

• Быстрый / производительный запрос
• Любые приращения времени, 21:01, 12:14 и т. д.
• Международный (?) - не уверен, что это проблема даже с часовыми поясами, по крайней мере, в моем случае, но кто-то более сведущий здесь, не стесняйтесь вмешиваться
• Открыто — Закрытие до следующего дня (открытие в полдень, закрытие в 2:00)
• Несколько промежутков времени / день
• Возможность переопределить определенные дни (праздники, что угодно)
• Возможность повторяющихся переопределений
• Возможность запрашивать любой момент времени и открывать бизнес (сейчас, будущее время, прошлое время)
• Возможность легко исключить результаты закрытия предприятий в ближайшее время (отфильтруйте предприятия, закрывающиеся через 30 минут, вы не хотите, чтобы ваши пользователи были «тем парнем, который появляется за 5 минут до закрытия в индустрии продуктов питания / напитков»).

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

Вот что я предлагаю для алгоритма и структуры.

Мы должны сделать некоторые конкретные предположения по всему миру, в любом месте и в любое время: в неделе 7 дней. В сутках 1440 минут. Существует конечное число возможных комбинаций минут открытия/закрытия.

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

Я предлагаю 3 таблицы: Прежде чем вы перестанете читать, учтите, что в реальном мире 2 из этих таблиц будут достаточно аккуратно кэшированы. Этот подход подойдет не всем из-за огромной сложности кода, необходимого для интерпретации пользовательского интерфейса в модели данных и обратно, если это необходимо. Ваш пробег и потребности могут отличаться. Это попытка разумного решения на уровне предприятия, что бы это ни значило.

Таблица часов работы

ID | ОТКРЫТО (минуты дня) | ЗАКРЫТЬ (минуты дня)

1 | 360 | 1020 (пример: с 9:00 до 17:00)

2 | 365 | 1021 (пример: пограничный регистр 9:05 - 17:01 (чудаки))

и т.п.

HoursOfOperations не волнует, какие дни, просто открытые и закрытые и уникальность. На комбинацию открытия/закрытия может быть только один вход. Теперь, в зависимости от вашей среды, либо вся эта таблица может быть кэширована, либо она может кэшироваться для текущего часа дня и т. д. В любом случае вам не нужно запрашивать эту таблицу для каждой операции. В зависимости от вашего решения для хранения я предполагаю, что каждый столбец в этой таблице проиндексирован для повышения производительности. С течением времени эта таблица, вероятно, имеет экспоненциально обратную вероятность INSERT(ов). Однако на самом деле работа с этой таблицей должна быть в основном внутрипроцессной операцией (ОЗУ).

Business2HoursКарта

Примечание. В моем примере я сохраняю «День» в виде поля/столбца с битовым флагом. Во многом это связано с моими потребностями и продвижением перечислений LINQ/Flags в C#. Ничто не мешает вам расширить это до 7-битных полей. Оба подхода должны быть относительно похожи как в логике хранения, так и в подходе к запросам.

Еще одно примечание: я не вступаю в семантический аргумент о том, что «каждой таблице нужен столбец идентификатора PK», пожалуйста, найдите для этого другой форум.

Идентификатор бизнеса | Идентификатор часов | День (или, если хотите, разделить на: BIT Monday, BIT вторник, ...)

1 | 1 | 1111111 (этот бизнес работает с 9 до 5 каждый день недели)

2 | 2 | 1111110 (эта компания открыта с 9:05 до 5:01 Пн-Сб (понедельник = день 1)

Причина, по которой это легко запросить, заключается в том, что мы всегда можем довольно легко определить MOTD (минуту дня), которая нам нужна. Если я хочу знать, что открыто завтра в 17:00, я беру все идентификаторы HoursOfOperations WHERE Close >= 1020. Если я не ищу временной диапазон, Open становится незначительным. Если вы не хотите показывать, что предприятия закрываются в ближайшие полчаса, просто соответствующим образом измените время прибытия (ищите 17:30 (10:50), а не 17:00 (10:20). Второй запрос, естественно, будет ' дайте мне все дела с HoursID IN (1, 2, 3, 4, 5) и т. д. Это, вероятно, должно поднять красный флаг, поскольку у этого подхода есть ограничения.Однако, если кто-то может ответить на фактический вопрос о перестановках выше, мы можем быть в состоянии опустить красный флаг.Учтите, что нам нужны только возможные перестановки на любой стороне уравнения одновременно, либо открытые, либо закрытые.

Учитывая, что у нас есть наша первая таблица в кэше, это быстрая операция. Вторая операция запрашивает эту потенциально большую таблицу строк, но мы ищем очень маленькие (SMALLINT) столбцы, которые, как мы надеемся, проиндексированы.

Теперь вы можете видеть сложность кода. В моем конкретном проекте я ориентируюсь в основном на бары, поэтому можно с уверенностью предположить, что у меня будет значительное количество предприятий с такими часами, как «11:00 - 2:00 (следующего дня)». Это действительно будет 2 записи как в таблице HoursOfOperations, так и в таблице Business2HoursMap. Например. бар, который открыт с 11:00 до 2:00, будет иметь 2 ссылки на таблицу HoursOfOperations 660–1440 (11:00–полночь) и 0–120 (полночь–2:00). Эти ссылки будут отражены в фактических днях в таблице Business2HoursMap как 2 записи в нашем упрощенном случае, 1 запись = ссылка на все дни № 1, еще одна ссылка на все дни № 2. Надеюсь, это имеет смысл, это был долгий день.

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

Идентификатор часов | Идентификатор бизнеса | день | Месяц | Год

1 | 2 | 1 | 1 | НУЛЕВОЙ

Это, безусловно, может стать более сложным, если вам нужно что-то вроде «каждый второй вторник эта компания ходит на рыбалку на 4 часа». Однако то, что это позволит нам сделать довольно легко, это разрешить 1 - переопределения, 2 - разумные повторяющиеся переопределения. НАПРИМЕР. если год равен NULL, то каждый год в день Нового года этот странный бар открыт с 9:00 до 17:00, что соответствует приведенным выше примерам данных. т.е. - Если указан год, то это только для 2013 года. Если месяц равен нулю, это каждый первый день месяца. Опять же, это не будет обрабатывать каждый сценарий планирования только по столбцам NULL, но теоретически вы можете справиться практически с чем угодно, полагаясь при необходимости на длинную последовательность абсолютных дат.

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

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

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

Любая другая система (например, диапазоны) будет очень раздражать, когда вы пересечете границу полуночи.

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

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

Существует так много исключений — и на регулярной основе (например, снежные дни, нерегулярные праздники, такие как Пасха, Страстная пятница), что, если ожидается, что это надежное представление реальности (в отличие от хорошего предположения), вам понадобится чтобы решить эту проблему довольно скоро в архитектуре.

Как насчет такого:

Таблица часов работы магазина

Business_id (int)
Start_Time (time)
End_Time (time)
Condition varchar/string
Open bit

«Условие» — это лямбда-выражение (текст предложения «где»). Создайте запрос динамически. Таким образом, для конкретного бизнеса вы выбираете все время открытия/закрытия.

Let Query1 = select count(open) from store_hours where @t between start_time and end_time and open  = true and business_id = @id and (.. dynamically built expression)

Let Query2 = select count(closed) from store_hours where @t between start_time and end_time and open = false and business_id = @id and (.. dynamically built expression)

Итак, в конце вы хотите что-то вроде:

select cast(Query1 as bit) & ~cast(Query2 as bit)

Если результат последнего запроса равен 1, то магазин открыт в момент времени t, иначе он закрыт.

Теперь вам просто нужен дружественный интерфейс, который может генерировать для вас предложения where (лямбда-выражения).

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

Конечно, здесь не нужно экономить память, но, возможно, нужен чистый и понятный код. ИМХО "поковыряться" - это не выход.

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

Концепция: присваивайте порядковый номер каждому 15-минутному блоку, начиная, скажем, с полуночи воскресенья.

Инициализация: вставьте в набор порядковый номер каждого 15-минутного блока, когда вы открыты. (Предполагая, что вы открыты меньше часов, чем закрыты.)

Использование: вычтите из интересного времени в минутах полночь предыдущего воскресенья и разделите на 15. Если это число присутствует в наборе, вы открыты.