В каких случаях фактически используются битемпоральные таблицы?

Question

Я пытаюсь собрать информацию о временных базах данных. Я знаю, что это не современная технология, но я видел, что многие люди, работающие с базами данных, никогда не знают, как работает временный подход (я спросил некоторых старших программистов и системных аналитиков о временных базах данных, и они ответили что-то вроде "А?"),

Я знаю, что существуют таблицы состояний действительного времени и таблицы состояний времени транзакции, а также битемпоральные таблицы. Я думаю, что битемпоральные таблицы слишком сложны для большинства применений, потому что в настоящее время пространство больше не является проблемой, и более эффективно записывать одну и ту же информацию в 2 разные таблицы, даже если данные избыточны. Тем не менее, я сделал много поисков в Интернете, пытаясь увидеть, где на самом деле используются битемпоральные таблицы, но я не нашел ничего полезного.

Существуют ли случаи, когда использование битемпоральной таблицы действительно удобнее, чем таблицы состояний времени действия и времени транзакции по отдельности? Есть ли реальные примеры?

Answer 1

Конечно! Взять, к примеру, данные баланса. Вы обнаружите, что эта информация изменится с WD1 (рабочий день) на WD x из-за запоздалых данных, настроек, ручных ошибок и тому подобного.

Чтобы включить повторяемую отчетность, контрольный журнал и временные сравнения, необходимо вести запись о "старых" (недействительных?) Результатах. Bitemporal - отличный способ управлять такими обновлениями, особенно в течение дня. Я не думаю, что это сложно с точки зрения пользователя - просто еще один фильтр в предложении where.

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

Возвращаясь к случаям использования. Наличие действительного (рабочего) времени и времени транзакции (версии) в одной таблице позволяет:

• Повторяющиеся результаты (наличие отдельных таблиц и соответствующих обновлений может означать получение разных результатов для одного и того же запроса в два разных дня)
• Сопоставимые результаты (можно ответить на такие вопросы, как "каково было значение X, как мы его знали в момент Y?")
• Быстрые результаты (работает только с одной таблицей, обновляется прозрачно и легко в запросе).

В этом смысле это подходящая структура для использования во многих, если не во всех таблицах в DWh.

Answer 2

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

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

Разве это не всякая чашка чая, поскольку вы должны иметь возможность думать во временном измерении, а также об изменении версии объекта, как это делают все БД.

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