Таблицы периода времени применения

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

Тем не менее, я просто наткнулся на ссылку на что-то, что якобы в стандарте SQL:2011:

Из википедии:

По состоянию на декабрь 2011 года ИСО / МЭК 9075, Язык базы данных SQL:2011 Часть 2: SQL/Foundation включил в определения таблиц предложения для определения "таблиц периодов времени приложения" (действительные таблицы времени), "таблиц с системной версией" (время транзакции). таблицы) и "системные периодические таблицы времени приложения" (битемпоральные таблицы)

Этот PDF-файл на самом деле имеет код для этого (время приложения):

CREATE TABLE Emp(
ENo INTEGER,
EStart DATE,
EEnd DATE,
EDept INTEGER,
PERIOD FOR EPeriod (EStart, EEnd)
)

Этот код не будет работать в SSMS. Что-то изменилось, что делает этот недействительный SQL сейчас? Похоже, что ранее недокументированная поддержка таблиц времени / битемпоральных таблиц была удалена?

1 ответ

Решение

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

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

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

INSERT INTO Emp
VALUES (22217,
DATE ‘2010-01-01’,
DATE '2011-11-12', 3)

... который также недопустим в SQL Server по нескольким причинам и нарушает несколько рекомендаций по загрузке. Может быть, все это допустимо в DB2, как вы предлагаете, но стандарт не должен зависеть от поставщика. Я имею в виду, по определению, если не что иное.

IBM DB2 поддерживает то, о чем вы спрашиваете. Думайте о стандарте SQL как об определении рекомендуемого способа, которым поставщик должен представить функцию, если он ее поддерживает, по крайней мере после SQL 92, который является своего рода ядром. В истории диалектов SQL иногда производители опережают стандарты, и диалекты расходятся. Вендору было бы глупо реализовывать функцию нестандартным способом после того, как она была стандартизирована, но иногда это происходит. Горячий слева, холодный справа; это стандарт. Это работает наоборот, но люди, как правило, обжигаются.

В этом случае, похоже, IBM решила внедрить эту функцию и сделать свой способ внедрения ее частью стандарта одним махом. Microsoft еще не решила, что это стоит их проблем.

Другие вопросы по тегам