Полная история базы - как лучше сделать?
Полная история базы - как лучше сделать?
Уважаемые знатоки и спецы в области IB и FB, к вам обращаюсь я.
Юзера хотят иметь полную историю БД. Кто, когда, какую запись внёс, изменил или удалил.
Как сие лучше сделать?
Пока сообразили в виде таблицы с полями <код юзера|код операции|имя таблицы|id записи|прежнее значение|новое значение>. Два последних поля получаются блобы, в которые придётся паковать/распаковывать записи.
Верный ли это путь? Где можно взглянуть на примеры реализации подобного? Чем и как лучше паковать и распаковывать записи в блобы?
Кто что может высказать, не молчите пожалуйста.
Юзера хотят иметь полную историю БД. Кто, когда, какую запись внёс, изменил или удалил.
Как сие лучше сделать?
Пока сообразили в виде таблицы с полями <код юзера|код операции|имя таблицы|id записи|прежнее значение|новое значение>. Два последних поля получаются блобы, в которые придётся паковать/распаковывать записи.
Верный ли это путь? Где можно взглянуть на примеры реализации подобного? Чем и как лучше паковать и распаковывать записи в блобы?
Кто что может высказать, не молчите пожалуйста.
-
- Сообщения: 52
- Зарегистрирован: 28 сен 2007, 10:19
Прочитал я эту статью и остался неудовлетворён, хотя что-то по мелочи извлёк.belov-evgenii писал(а):http://rsdn.ru/article/db/dbhistory.xml
Там называется несколько способов организовать историю.
1. Таблицы-двойники. Не подходит, ибо заколупаешься создавать и поддерживать дополнительные N таблиц. Если бы log N, а лучше k.
3. Таблицы версий. Схему я обдумывал и помимо статьи, и она бы мне и интересна весьма - очень вкусно теоретически выглядит, но неясна реализация. Здесь таблица превращается в метатаблицу, и хранит не записи, а таймлайны записей - деревья истории записи. Тут нужно собраться и заново изобрести вставку, выборкуи т.д.
2. Единая таблица аудита. Это то, на чём пока остановились. Статья предупреждает насчёт проблемы с блокировкой. Интересно услышать мнение именно по IB/FB, наблюдается ли реально эта проблема?
Ещё заинтересовала идея отдельной подчинённой таблицы полей, с записями вида <id записи в таблице аудита|название поля|значение поля>. Это вроде как позволяет обойтись без паковки записей в блобы. Только вот нужен тип variant, а есть ли такой в IB/FB? Можно ли записать значение разных типов в одну колонку таблицы? Или всё же придётся как-то паковать в блобы.
Прошу высказываться всех, кто что-то делал по этой теме. Поделитесь опытом, пожалуйста.
Так-так, это м.б. решение. Если сервер IB/FB позволяет кастовать любой тип в VARCHAR, то со вставкой в историю проблем не будет.Attid писал(а):есть =) varchar называется хрини хоть строки хоть даты хоть числа =)KKomov писал(а):Только вот нужен тип variant, а есть ли такой в IB/FB?
Ещё только нужно суметь извлечь из истории значение любого типа. Для этого нужно как-то этот самый тип записывать рядом, т.е. запись подчинённой таблицы полей принимает вид <id записи в таблице аудита|название поля|тип поля|значение поля>.
Итого, по этой схеме реализации истории непонятки конкретизируются до вот каких вопросов:
1. Как наиболее корректно и надёжно скастовать любой столбец к VARCHAR?
2. Как получить внутри хранимой процедуры тип столбца в каком-нибудь пригодном для вставки в историю виде?
3. Как затем прочитать тип столбца из истории и скастовать к нему из VARCHAR-а значение?
4. (программа максимум) Как на базе п.3 соорудить VIEW, через который видна история данной таблицы?
Кто делал такую схему и имеет под рукой готовый код, помогите изобрести пожалуйста. Также у кого есть соображения, не дайте им пропасть, поделитесь пожалуйста.
http://www.ibase.ru/devinfo/oop_rdbms.htm
вообще идея при фиксированной структуре хранить историю изменений ВСЕХ типов весьма сомнительна. Потому что даже при небольшом количестве самих действий по изменению данных количество записей "лога" и его объем будет гигантским. Поэтому я считаю такую идею теоретически возможной, но практически неработоспособной.
Если ты искал на эту тему, и ничего не нашел, это еще раз подтверждает мой тезис.
второй раз, кстати, спрашиваю. IBLogmanager смотрел?
вообще идея при фиксированной структуре хранить историю изменений ВСЕХ типов весьма сомнительна. Потому что даже при небольшом количестве самих действий по изменению данных количество записей "лога" и его объем будет гигантским. Поэтому я считаю такую идею теоретически возможной, но практически неработоспособной.
Если ты искал на эту тему, и ничего не нашел, это еще раз подтверждает мой тезис.
второй раз, кстати, спрашиваю. IBLogmanager смотрел?