Краткий ответ

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

Исторический контекст

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

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

Постановка проблемы

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

Неверный выбор типа приводит к неоднозначным данным, ошибкам при сложении с датами и несогласованной логике в разных сервисах. Однако INTERVAL не всегда лучше: для измерения точного elapsed time между двумя событиями числовое значение в миллисекундах или секундах может быть проще и однозначнее.

Подробное решение

INTERVAL следует выбирать, когда единица измерения является частью бизнес-смысла. Например, срок хранения «6 месяцев», период оплаты «30 дней» или задержка «15 минут» естественно моделируются временными интервалами.

CREATE TABLE jobs (
    job_id INTEGER PRIMARY KEY,
    timeout INTERVAL NOT NULL
);

INSERT INTO jobs VALUES (1, INTERVAL '15 minutes');

SELECT CURRENT_TIMESTAMP + timeout AS deadline
FROM jobs;

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

Важно различать два смысла. Календарный интервал вроде «один месяц» применяется к календарной дате и не обязан быть равен фиксированному числу дней. Физическая длительность вроде «ровно 86 400 секунд» лучше представляется числом секунд или интервалом, заданным в секундах, если конкретная СУБД обеспечивает нужную точность и правила вычисления.

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

Ситуация из практики

Сервис подписок должен вычислять дату окончания тарифа через шесть календарных месяцев. Команда сначала выбрала число дней и записала значение 180. Такой вариант прост, но неверно моделирует месячный срок: разные месяцы имеют разную длину, поэтому дата окончания может отличаться от бизнес-правила.

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

Выбран INTERVAL с календарными месяцами вместе с датой начала. Это сохраняет бизнес-смысл срока и позволяет СУБД выполнять календарную арифметику. Для отдельного мониторинга фактической продолжительности операции команда дополнительно использовала числовое значение в миллисекундах, потому что это уже другой смысл данных.

Что кандидаты часто упускают

Равен ли интервал в один месяц фиксированному числу дней?

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

Почему для времени выполнения запроса часто выбирают число миллисекунд, а не месячный интервал?

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

Достаточно ли типа INTERVAL, чтобы одинаково вычислять сроки во всех СУБД?

Нет. Стандарт задает общую концепцию интервального типа, но конкретные СУБД могут различаться синтаксисом литералов, поддерживаемыми диапазонами, точностью, нормализацией и поведением при добавлении интервала к датам. Переносимая модель требует проверять эти особенности и закреплять правила вычислений на уровне проекта.