Механизм устройства хранения данных базы данных управления версиями существуют?
Я просто задавался вопросом, существовал ли тип механизма устройства хранения данных, который позволил Вам делать управление версиями на содержании уровня строки. Например, если у меня есть простая таблица с идентификатором, именем, значением, и идентификатором является PK, я видел, что строка 354 запустилась, поскольку (354, "zak", "тест") v1 затем был обновлен, чтобы быть (354, "zak", "это - версия 2 значения"), v2, и видел историю изменений на строке с чем-то как избранная история (значение) где идентификатор = 354.
Это - вид тайной вещи, но это разбило бы необходимость продолжать писать этим отдельным таблицам истории и функциям каждый раз, когда изменение внесено...
10 ответов
Похоже, вам нужны дополнительные функции аудита. Oracle и несколько других СУБД имеют полные функции аудита. Но многие администраторы баз данных по-прежнему реализуют аудит строк на основе триггеров. Все зависит от ваших потребностей.
Oracle поддерживает несколько уровней детализации аудита, которые легко настроить из командной строки.
Я вижу, что вы помечены как MySQL, но спрашивали о каком-либо механизме хранения. Во всяком случае, другие ответы говорят то же самое, поэтому я собираюсь удалить этот пост, поскольку изначально он был о функциях ретроспективного кадра.
Вы можете добиться аналогичного поведения с триггерами (ищите «триггеры для отслеживания всех изменений базы данных») - особенно если они реализуют SQL92 INFORMATION_SCHEMA .
В противном случае я бы согласился с mrjoltcola
Edit: Единственная проблема, которую я бы упомянул с MySQL и триггерами, заключается в том, что (начиная с последней версии сообщества, которую я скачал), требуется, чтобы учетная запись пользователя имела SUPER привилегия, которая может сделать вещи немного уродливыми
CouchDB поддерживает полное управление версиями для каждого внесенного изменения, но это часть мира NOSQL, поэтому, вероятно, это будет довольно сумасшедший переход от того, что вы делаете в настоящее время .
В статье википедии в большой таблице Google упоминается, что она позволяет управлять версиями путем добавления измерения времени в таблицы:
Каждая таблица имеет несколько измерений (одно из которых - поле для времени, позволяющее управлять версиями).
Там также есть ссылки на несколько реализаций СУБД типа bigtable, не принадлежащих Google.
Я думаю, что Big table, движок Google DB, делает что-то подобное : он связывает временную метку с каждым обновлением строки.
Возможно, вам стоит попробовать Google App Engine.
Есть статья Google, объясняющая , как работает Большой стол .
В книге Рефакторинг баз данных есть некоторые идеи по этому поводу.
Но это также указывает на то, что в настоящее время нет реального решения, кроме тщательного внесения изменений и управления ими вручную.
Одним из приближений к этому является временная база данных, которая позволяет вам видеть состояние всей базы данных в разное время в прошлом. Я не уверен, что полностью ответил на ваш вопрос; он не позволит вам увидеть содержимое строки 1 в момент времени t1, одновременно позволяя просматривать содержимое строки 2 в отдельный момент времени t2.
"Это своего рода эзотерическая вещь, но она бы лучше, чем необходимость писать эти отдельные таблицы истории и функции каждый раз, когда вносятся изменения ..."
Я бы не назвал контрольные журналы (о чем вы, очевидно, говорите) «эзотерической вещью» ...
И: все еще существует разница между историей обновлений базы данных и историей реальность. Таблицы исторической базы данных действительно должны использоваться для отражения истории реальности, НЕ истории обновлений базы данных.
История обновлений базы данных уже хранится СУБД в своих журналах и журналах. Если кому-то нужно узнать историю обновлений базы данных, то ему / ей действительно следует прибегнуть к журналам и журналам, а не к какой-либо конструкции уровня приложения, которая НИКОГДА не может обеспечить достаточную гарантию того, что она отражает ] ВСЕ обновления.
Очевидно, что вам действительно нужно решение MySQL, так что это, вероятно, вам не сильно поможет, но в Oracle есть функция под названием Total Recall (более формально Flashback Archive), которая автоматизирует процесс, который вы сейчас выполняете вручную. Архив - это набор сжатых таблиц, в которые автоматически вносятся изменения и которые можно запрашивать с помощью простого синтаксиса AS OF .
Естественно, поскольку они Oracle, они взимают за это плату: увы, требуется дополнительная лицензия поверх Enterprise Edition. Подробнее (PDF).
Oracle и Sql Server называют эту функцию Change Data Capture. В настоящее время эквивалента для MySql не существует.