Существует ли механизм хранения базы данных управления версиями?

Question

Мне было просто интересно, существует ли тип механизма хранения, который позволял бы вам контролировать версии на уровне строк. Например, если у меня есть простая таблица с идентификатором, именем, значением и идентификатором является PK, я мог видеть, что строка 354 начиналась как (354, "zak", "test") v1, затем обновлялась до (354, "zak", "это версия 2 значения") v2, и может видеть историю изменений в строке с чем-то вроде истории выбора (значения), где ID = 354.

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

Answer 1

Очевидно, что вы действительно ищете решение MySQL, так что это, вероятно, вам мало поможет, но в Oracle есть функция Total Recall (более формально Flashback Archive), которая автоматизирует процесс, который вы в данный момент выполняете вручную. Архив представляет собой набор сжатых таблиц, которые заполняются изменениями автоматически и могут запрашиваться с простым синтаксисом AS OF.

Естественно, что, будучи Oracle, они платят за это: ей, увы, нужна дополнительная лицензия поверх Enterprise Edition. Узнать больше (PDF).

Answer 2

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

Oracle поддерживает несколько гранул аудита, которые легко настраиваются из командной строки.

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

Answer 3

Книга Рефакторинг баз данных содержит некоторые сведения по этому вопросу.

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

Answer 4

В статье Википедии на большой таблице Google упоминается, что она позволяет создавать версии, добавляя измерение времени в таблицы:

Каждая таблица имеет несколько измерений (одно из которых является полем для времени, разрешение версий).

Там также есть ссылки на несколько не связанных с Google реализаций dbms типа bigtable.

Answer 5

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

Answer 6

Я думаю, что Big table, движок Google DB, делает что-то подобное: он ассоциирует отметку времени с каждым обновлением строки.

Может быть, вы можете попробовать Google App Engine.

В Google есть статья, объясняющая , как работает Big Table .

Answer 7

Oracle и Sql Server оба называют эту функцию Change Data Capture. На данный момент для MySql нет эквивалента.

Answer 8

Вы можете добиться аналогичного поведения с помощью триггеров (ищите «триггеры, чтобы перехватить все изменения базы данных») - особенно если они реализуют SQL92 INFORMATION_SCHEMA.

В противном случае я бы согласился с mrjoltcola

Редактировать: Единственное замечание, которое я упомянул о MySQL и триггерах, это то, что (начиная с последней загруженной мной версии сообщества) требуется, чтобы учетная запись пользователя имела привилегию SUPER, что может сделать немного уродливым

Answer 9

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

Я бы не назвал журналы аудита (о чем вы, конечно, говорите) "эзотерикой" ...

И еще: есть разница между историей обновлений базы данных и историей реальности. Исторические таблицы базы данных должны действительно использоваться для отражения истории реальности, НЕ истории обновлений базы данных.

История обновлений базы данных уже хранится СУБД в ее журналах и журналах. Если кому-то нужно узнать историю обновлений базы данных, он должен действительно прибегнуть к журналам и журналам, а не к какой-либо конструкции уровня приложения, которая может НИКОГДА не дать достаточной гарантии, что она отражает ВСЕ обновления.

Answer 10

Одним из приближений к этому является временная база данных, которая позволяет вам видеть состояние всей базы данных в разное время в прошлом. Я не уверен, что полностью отвечает на ваш вопрос, хотя; это не позволит вам увидеть содержимое строки 1 в момент времени t1, одновременно позволяя вам просматривать содержимое строки 2 в отдельное время t2.