Подтвердить что ты не робот

PHP/Oracle: представление времени

Отказ от ответственности: Я прекрасно понимаю, что лучший способ представить дату/время - это временные метки Unix или PHP DateTime и тип данных Oracle DATE.

С этой точки зрения мне интересно, какие наиболее подходящие типы данных (как в PHP, так и в Oracle) для хранения только времени. Мне не интересно хранить компонент date; только время.

Например, скажем, у меня был объект employee, для которого я хотел сохранить его/ее типичный график работы. Этот сотрудник может работать с 8:00 до 17:00. В эти моменты нет компонентов даты, и что их следует использовать для их хранения и представления?

Параметры, которые я рассмотрел:

  • Как строки со стандартным форматом (вероятно, 24-часовая ЧЧ: ММ: СС + З).
  • Как числа в диапазоне 0 <= n < 24, с дробными частями, представляющими минуты/секунды (не удается сохранить информацию о часовом поясе?).
  • Как PHP DateTime и Oracle DATE с нормализованным/неиспользуемым компонентом даты, например 0001-01-01.
  • То же, что и выше, только с использованием временных меток Unix (PHP integer и Oracle TIMESTAMP).

В настоящее время я использую # 3 выше, но это меня раздражает, что кажется, что я неправильно использую эти типы данных. Однако, насколько я могу судить, он обеспечивает наилучшее удобство использования. Сравнение и сортировка всей работы, как ожидалось, в PHP и Unix, данные о часовом поясе могут поддерживаться, и на самом деле нет необходимости в каких-либо специальных манипуляциях для отображения данных.

Я пропускаю что-либо или есть более подходящий способ?

4b9b3361

Ответ 1

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

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

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

Итак, подведем итог:

  • Если вы хотите легко хранить, но не манипулировать данными, строки могут быть эффективный метод. Их легко читать и проверять. Для всего else, выберите что-то еще.
  • Вычисление в виде чисел делает для сверхлегких вычислений. Конвертировать время/дата до десятичной величины, сделайте все ваши тяжелые хиты, а затем вернитесь к формат реального времени и сохранение.
  • Оба Datetime и Oracle Date являются удобными, и есть некоторые фантастические функции, встроенные в оракул и PHP, чтобы манипулировать данных, но даже лучшие функции могут быть более сложными, чем добавление некоторые десятичные числа вместе. Я считаю, что хранение данных в база данных в формате даты, вероятно, является безопасной идеей - особенно если вы хотите выполнять вычисления на основе столбцов в запросе. То, что вы планируете делать с ними внутри PHP, определит, как вы используете их.
  • Я бы выбрал вариант четыре сразу с места в карьер.

Изменить: у меня просто был интересный чат с другом о типах времени. Еще одна вещь, о которой вы должны знать, это то, что иногда объекты, основанные на времени, могут вызвать больше проблем, чем они решают. Он изучал приложение, в котором мы отслеживаем даты и время доставки. Фактически данные хранились в объектах datetime, но вот улов: время доставки грузовика устанавливается для определенного дня и окна доставки. Допустимая доставка осуществляется вовремя или до часа после времени. Это вызвало некоторый хаос, когда грузовик должен был прибыть в 11:30 вечера и появился через 45 минут. Пока он находится в приемлемом окне, он появился на следующий день. Другая проблема была в распределительном центре, который фактически работает в 4 часа ночи, начиная с 24-часового дня. Время срабатывания персонала - и консолидация его к платежам, вращающимся вокруг обычной даты, оказалась довольно головной болью.

Ответ 2

Если вам вообще не нужна дата, то вам нужен тип данных interval day. У меня не было необходимости фактически использовать это, но следующее должно работать:

interval day(0) to second(6)

Ответ 3

Выбор, который вы используете (3), является лучшим.

Oracle имеет следующие типы для хранения времени и дат:

  • Дата
  • временная метка (с (местным) часовым поясом)
  • интервал год за месяцем
  • интервал от дня до второго

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

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

Дополнительная информация о типах дат оракула: http://docs.oracle.com/cd/B19306_01/server.102/b14225/ch4datetime.htm#i1005946