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

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

Однако я только что наткнулся на ссылку на что-то, что предположительно находится в стандарте SQL: 2011:

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

По состоянию на декабрь 2011 г. стандарт ISO/IEC 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 недопустимым? Похоже, то, что раньше было недокументированной поддержкой таблиц времени приложения/битемпоральных таблиц, теперь удалено?


sql-server-2016 bi-temporal temporal-database
person Crogacht    schedule 12.12.2018    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

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

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

person Aaron Bertrand    schedule 12.12.2018
comment
Ok. Я понимаю это, но мне любопытно, откуда взялся код в этом .pdf, если он был и никогда не был действительным. Они просто теоретизировали и опубликовали это? - person Crogacht; 13.12.2018
comment
Это просто пример того, как это можно сделать в коде. - person Aaron Bertrand; 13.12.2018
comment
Только что заметил, что это IBM, так может и в DB2 можно? Это, вероятно, ответ. - person Crogacht; 13.12.2018

arrow_upward
0
arrow_downward

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

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

person Chris Golledge    schedule 03.05.2019