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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 4

Oracle и Sql Server называют эту функцию Change Data Capture. В настоящее время для MySql нет эквивалента.

Ответ 5

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

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

В документе Google есть описание того, как работает Big Table.

Ответ 6

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

Ответ 7

статья wikipedia на google bigtable упоминает, что она позволяет управлять версиями, добавляя измерение времени к таблицам:

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

Есть также ссылки на несколько не-google реализаций dbms большого табличного типа.

Ответ 9

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

Ответ 10

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

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

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

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