SQL Server: наиболее оптимальный способ хранения времени (без даты)

Здесь еще один или более для совершенства.

Microsoft SQL Server содержит только тип поля datetime для хранения дат и времени.

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

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

И поэтому он задает вопрос; в отсутствие конкретного поля time (как в MySQL), что является наиболее оптимальным способом хранения только определенного времени суток с 00:00 до 23:59?

UPDATE: это SQL Server 2005. (Также мне просто интересно узнать, что делать вообще, когда нет типа time.)

Ответ 1

Для SQL Server 2005 или старше...

Если вы хотите узнать только минуту, вы можете сохранить его как int в диапазоне 1-1440. 1 равно 00:01, а 1440 - 0:00.

Было бы легко отобразить как можно больше времени, если хотите:

SELECT CAST((605 / 60) as varchar) + ':' + RIGHT('0' + CAST((605 % 60) as varchar), 2)

Дополнительным преимуществом этого является то, что если вы используете тип данных smallint, вы сохраняете 1-3 байта на запись из встроенного типа данных TIME.

TIME использует 3-5 байт на строку, а smallint - 2 байта на строку.

Дополнительные байты относятся к секундам и дробным секундам, которые я считаю.

ИЗМЕНИТЬ

Это сложнее с секунд, но все же выполнимо, я должен подумать...

1-86400 диапазон (секунды в день)

DECLARE @i INT
SET @i = 3661

SELECT RIGHT('0' + CAST((@i / 3600) as varchar),2) --hours
+ ':' + RIGHT('0' + CAST((@i % 3600)/60 as varchar), 2) -- minutes
+ ':' + RIGHT('0' + CAST((@i % 3600)%60 as varchar), 2) -- seconds

Ответ 4

Лично я бы не рассматривал поднятые точки как достаточные, чтобы отойти от использования DATETIME или SMALLDATETIME.

  • INT использует 4 байта, как и SMALLDATETIME
  • Люди делают ошибки с SMALLINT, которые вызывают неявные преобразования типов (увеличение загрузки процессора)
  • Дисковое пространство дешево, вам нужно много байтов, чтобы добавить любое существенное
  • Код, например WHERE minutes < 720, менее понятен, чем WHERE time < '12:00'
  • Проблемы с отображением (например, преобразование DATETIME в hh: mm) часто являются лучшим местом в клиенте
  • Использование DATETIME позволяет гибкость в будущем, например, переход на несколько секунд вместо минут

Тем не менее, я использовал поля INTEGER для хранения нескольких секунд, например, когда они используются преимущественно для вычисления средних длительностей и т.д.

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

Ответ 5

SQL 2008 исправил эту проблему, как отмечали другие, но в 2005 году:

Вам нужно выполнить математику по времени? Если нет, вы можете сохранить его как строку.

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

И да, datetime является неуклюжим для хранения только времени, но он отлично работает.