iBase.ru Forum

Уважаемые знатоки и спецы в области IB и FB, к вам обращаюсь я.

Юзера хотят иметь полную историю БД. Кто, когда, какую запись внёс, изменил или удалил.

Как сие лучше сделать?

Пока сообразили в виде таблицы с полями <код юзера|код операции|имя таблицы|id записи|прежнее значение|новое значение>. Два последних поля получаются блобы, в которые придётся паковать/распаковывать записи.

Верный ли это путь? Где можно взглянуть на примеры реализации подобного? Чем и как лучше паковать и распаковывать записи в блобы?

Кто что может высказать, не молчите пожалуйста.

belov-evgenii писал(а):http://rsdn.ru/article/db/dbhistory.xml

Прочитал я эту статью и остался неудовлетворён, хотя что-то по мелочи извлёк.

Там называется несколько способов организовать историю.

1. Таблицы-двойники. Не подходит, ибо заколупаешься создавать и поддерживать дополнительные N таблиц. Если бы log N, а лучше k.

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

2. Единая таблица аудита. Это то, на чём пока остановились. Статья предупреждает насчёт проблемы с блокировкой. Интересно услышать мнение именно по IB/FB, наблюдается ли реально эта проблема?

Ещё заинтересовала идея отдельной подчинённой таблицы полей, с записями вида <id записи в таблице аудита|название поля|значение поля>. Это вроде как позволяет обойтись без паковки записей в блобы. Только вот нужен тип variant, а есть ли такой в IB/FB? Можно ли записать значение разных типов в одну колонку таблицы? Или всё же придётся как-то паковать в блобы.

Прошу высказываться всех, кто что-то делал по этой теме. Поделитесь опытом, пожалуйста.

Только вот нужен тип variant, а есть ли такой в IB/FB?

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

Можно ли записать значение разных типов в одну колонку таблицы?

нет

Поделитесь опытом, пожалуйста.

logmanager смотрел? Сам что-нибудь искал?

KKomov писал(а):Только вот нужен тип variant, а есть ли такой в IB/FB?

есть =) varchar называется хрини хоть строки хоть даты хоть числа =)

Attid писал(а):varchar называется хрини хоть строки хоть даты хоть числа =)

А блобы как? А массивы?

массивы? массивы, оно конечно... без массивов-то как же? А никак без массивов...

А блобы как?

блобы в историю ?
да в лес пусть идут, нечего над птичкой издеваться =)
вывод diff пусть хранить =)

А массивы?

не разу еще не видел где бы их реально можно применить =/

Attid писал(а):

KKomov писал(а):Только вот нужен тип variant, а есть ли такой в IB/FB?

есть =) varchar называется хрини хоть строки хоть даты хоть числа =)

Так-так, это м.б. решение. Если сервер IB/FB позволяет кастовать любой тип в VARCHAR, то со вставкой в историю проблем не будет.

Ещё только нужно суметь извлечь из истории значение любого типа. Для этого нужно как-то этот самый тип записывать рядом, т.е. запись подчинённой таблицы полей принимает вид <id записи в таблице аудита|название поля|тип поля|значение поля>.

Итого, по этой схеме реализации истории непонятки конкретизируются до вот каких вопросов:

1. Как наиболее корректно и надёжно скастовать любой столбец к VARCHAR?

2. Как получить внутри хранимой процедуры тип столбца в каком-нибудь пригодном для вставки в историю виде?

3. Как затем прочитать тип столбца из истории и скастовать к нему из VARCHAR-а значение?

4. (программа максимум) Как на базе п.3 соорудить VIEW, через который видна история данной таблицы?

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

http://www.ibase.ru/devinfo/oop_rdbms.htm

вообще идея при фиксированной структуре хранить историю изменений ВСЕХ типов весьма сомнительна. Потому что даже при небольшом количестве самих действий по изменению данных количество записей "лога" и его объем будет гигантским. Поэтому я считаю такую идею теоретически возможной, но практически неработоспособной.

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

второй раз, кстати, спрашиваю. IBLogmanager смотрел?