Зачем нам временная база данных?

рассмотрим ваше назначение / дневник журнала-он идет с 1 января по 31 декабря. Теперь мы можем запросить дневник для встреч / записей журнала в любой день. Этот порядок называется действительное время. Однако назначения / записи обычно не вставляются по порядку.

предположим, я хотел бы знать, какие встречи/записи были в моем дневнике 4 апреля. То есть все записи, которые существовали в моем дневнике 4 апреля. Это сделки время.

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

эта договоренность необходима, когда дневник может пройти исторические редакции. Предположим, 5 апреля я осознаю, что встреча, назначенная на 14 февраля, на самом деле произошла 14 февраля. 12 февраля т. е. я обнаруживаю ошибку в своем дневнике - Я могу исправить ошибку, чтобы исправить действительное изображение времени, но теперь мой запрос о том, что было в дневнике 4 апреля, будет неправильным, если только не будут сохранены времена транзакций для встреч/записей. В этом случае, если я запрошу свой дневник от 4 апреля, он покажет, что встреча была 14 февраля, но если я запрошу от 6 апреля, он покажет встречу 12 февраля.

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

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

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

Как я понимаю (и чрезмерно упрощая), временная база данных записывает факты о том, когда данные были действительными, а также сами данные, и позволяет вам запрашивать временные аспекты. Вы в конечном итоге имеете дело с 'Время действия' и 'время' таблиц, или битемпоральная столы' с участием 'правильное время' и 'время' аспекты. Следует учитывать, читая эти две книги:

• Дарвен, дата и Lorentzos "временные данные и реляционная модель" (вышел из печати),
• и (в радикально иной крайности)"разработка приложений баз данных, ориентированных на время в SQL", Ричард Т. Снодграсс, Издатели Морган Кауфманн, Инк. Сан-Франциско, в июле 1999 года, 504+ХХІІІ страниц и ISBN 1-55860-436-7. Это не напечатано, но доступно в формате PDF на его веб-сайте по адресуcs.arizona.edu (таким образом, поиск Google делает его довольно легко найти).

темпоральные базы данных часто используются в индустрии финансовых услуг. Одна из причин заключается в том, что вам редко (если когда - либо) разрешено удалять какие-либо данные, поэтому поля типа ValidFrom-ValidTo в записях используются для указания того, когда запись была правильной.

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

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

несмотря на это, временные данные обычно просто хранится в обычной РСУБД. PostgreSQL, например, имеет некоторые временные расширения, что делает это немного проще.

на ум приходят две причины:

1. некоторые оптимизированы для вставки и только для чтения и могут предложить драматические улучшения perf
2. некоторые имеют лучшее понимание времени, чем традиционный SQL-что позволяет группировать операции по секундам, минутам, часам и т. д.

просто обновление, временная база данных поступает в SQL Server 2016.

чтобы очистить все ваши сомнения, зачем нужна временная база данных, а не настройка с помощью пользовательских методов, и насколько эффективно и плавно SQL Server настраивает ее для вас, проверьте углубленное видео и демо на Channel9.msdn здесь:https://channel9.msdn.com/Shows/Data-Exposed/Temporal-in-SQL-Server-2016

MSDN ссылка: https://msdn.microsoft.com/en-us/library/dn935015 (v=sql.130).aspx

В настоящее время с выпуском CTP2 (beta 2) SQL Server 2016 вы можете играть с ним.

Регистрация видео о том, как использовать временные таблицы в SQL Server 2016.

кроме того, "какие новые вещи я могу с ним сделать", было бы полезно рассмотреть " какие старые вещи он объединяет?". Временная база данных представляет собой конкретное обобщение "нормальной" базы данных SQL. Таким образом, это может дать вам единое решение проблем, которые ранее казались несвязанными. Например:

• Веб-Параллелизм когда ваша база данных имеет веб-интерфейс, который позволяет нескольким пользователям выполнять стандартные изменения Create/Update/Delete (CRUD), вы придется столкнуться с проблема параллельных веб-изменений. В принципе, вам нужно проверить, что изменение входящих данных не влияет на записи, которые изменились с тех пор, как пользователь видел эти записи в последний раз. Но если у вас есть временная база данных, вполне возможно, что она уже связывает что-то вроде "идентификатора ревизии" с каждой записью (из-за сложности создания уникальных и монотонно возрастающих временных меток). Если это так, то это становится естественным," уже встроенным " механизмом для предотвращение блокирования данных других пользователей во время обновления базы данных.
• Юридические / Налоговые Записи правовая система (включая налоги) уделяет гораздо больше внимания историческим данным, чем большинство программистов. Таким образом, вы часто найдете советы о схемах счетов-фактур и таких, которые предупреждают вас остерегаться удаления записей или нормализации естественным образом, что может привести к неспособности ответить на основные юридические вопросы, такие как " забудьте их текущий адрес, что адрес вы отправили этот счет в 2001 году?"С временной базой данных все махинации с этими проблемами (они обычно являются промежуточными шагами к созданию временной базы данных) уходят. Вы просто используете самую естественную схему и удаляете, когда это имеет смысл, зная, что всегда можете вернуться и точно ответить на исторические вопросы.

с другой стороны, сама временная модель находится на полпути к завершению контроля ревизии, что может вдохновить дальнейшие приложения. Для например, предположим, вы катите свой собственный временной объект поверх SQL и разрешаете ветвление, как в системах контроля версий. Даже ограниченное разветвление может упростить предложение "песочницы" - возможность играть с базой данных и изменять ее без каких-либо видимых изменений для других пользователей. Это позволяет легко обеспечить реалистичное обучение пользователей сложной базе данных.

простое ветвление с помощью простого средства слияния также может упростить некоторые общие проблемы рабочего процесса. Например, некоммерческая организация может иметь добровольцев или низкооплачиваемых работников, выполняющих ввод данных. Предоставление каждому работнику своей собственной ветви может облегчить возможность для руководителя пересмотреть свою работу или улучшить ее (например, снять дублирование) перед объединением ее в основную ветвь, где она станет видимой "нормальным" пользователям. Ветви также могут упростить разрешения. Если пользователю предоставляется только разрешение на использование / просмотр своей уникальной ветви, вам не нужно беспокоиться о предотвращении всех возможных нежелательных модификация; вы все равно объедините только те изменения, которые имеют смысл.

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

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

есть академические базы данных и некоторые коммерческие. Timecenter имеет некоторые ссылки.

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

поэтому у нас было последнее чтение (наше "текущее понимание" потребления за 30 минут), но мы могли оглянуться на наше историческое понимание потребления. Когда у вас есть данные, которые можно настроить таким образом, временные базы данных работают хорошо.

(сказав это, мы вручную вырезали его в SQL, но это было довольно давно. В наши дни такое решение не принято.)