В каких ситуациях мне требуется хранить разные версии одних и тех же данных в базе данных?

Question

Это снимок бумаги Google BigTable

Какой может быть сценарий, в котором вместо того, чтобы иметь что-то вроде Oracle redo logs , мне нужно будет хранить несколько версий одних и тех же данных в базе данных ?

Если обратиться именно к этому примеру, зачем мне хранить несколько версий html-страницы в моей базе данных? Он не может выступать в качестве резервной копии, потому что в любом случае не существует всех версий, есть только некоторые (скажем, последние 5).

Answer 1

С BigTable и аналогичными нереляционными хранилищами следует признать, что у них совершенно другая модель согласованности.

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

Скажем, у вас есть запись, хранящаяся в узлах 'A' и 'B'. При репликации с несколькими хозяевами у вас нет понятия первичного и копируемого. Скорее всего, запись может быть обновлена ​​на обоих узлах одновременно (особенно, если связь между ними нарушена). Управление версиями может помочь решить возникающие проблемы согласованности.

Кроме того, эти базы данных, как правило, не выполняют «удаления». Вы просто сохраняете более новую версию, которая помечена как удаленная (или просроченная, или как угодно). Аналогичным образом, «откат» будет создавать более новую версию записи из более ранней.

Answer 2

Случаи:

Вы хотите знать, как Даа изменился в прошлом. Примеры: отслеживание статуса заказа по мере прохождения процесса. Отслеживайте адреса клиентов, даже когда они переехали.

Это может быть деловым требованием или юридическим требованием. Довольно часто оба.

Answer 3

Какие ситуации: получение представления данных «как было» - это может быть очень полезно для диагностики (т. Е. Возможность повторного запуска процесса с использованием тех же данных без восстановления всей базы данных). См. Oracle Flashback Query, чтобы узнать, как это сделать в короткие сроки.

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

(я не могу вспомнить конкретный термин для встроенного управления версиями строк в Oracle, где он эффективно хранит таблицу истории для каждой таблицы).

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

Answer 4

Вам известно, что (в дополнение к журналам повторов) Oracle также сохраняет предыдущие версии тех же данных (в табличном пространстве отмены)? Это называется многоверсионным управлением параллелизмом и позволяет выбирать без блокировки (вы можете выбрать предыдущее значение строки, которая изменяется текущей транзакцией, не дожидаясь принятия новых данных).

Answer 5

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

Answer 6

Если обратиться именно к этому примеру, зачем мне хранить несколько версий html-страницы в моей базе данных?

Если вы хотите вернуться к предыдущей версии.