Полная история базы - как лучше сделать?

Модераторы: kdv, CyberMax

Ответить
KKomov
Сообщения: 14
Зарегистрирован: 20 дек 2007, 17:30

Полная история базы - как лучше сделать?

Сообщение KKomov » 20 дек 2007, 17:50

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

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

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

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

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

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

belov-evgenii
Сообщения: 52
Зарегистрирован: 28 сен 2007, 10:19

Сообщение belov-evgenii » 20 дек 2007, 19:07


KKomov
Сообщения: 14
Зарегистрирован: 20 дек 2007, 17:30

Сообщение KKomov » 22 дек 2007, 19:34

belov-evgenii писал(а):http://rsdn.ru/article/db/dbhistory.xml
Прочитал я эту статью и остался неудовлетворён, хотя что-то по мелочи извлёк.

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

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

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

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

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

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

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 23 дек 2007, 04:13

Только вот нужен тип variant, а есть ли такой в IB/FB?
нет. такого типа вообще не существует, это фикция. см. исходники рантайма дельфей.
Можно ли записать значение разных типов в одну колонку таблицы?
нет
Поделитесь опытом, пожалуйста.
logmanager смотрел? Сам что-нибудь искал?

Attid
Спец
Сообщения: 377
Зарегистрирован: 14 ноя 2006, 09:58

Сообщение Attid » 25 дек 2007, 15:24

KKomov писал(а):Только вот нужен тип variant, а есть ли такой в IB/FB?
есть =) varchar называется хрини хоть строки хоть даты хоть числа =)

WildSery
Заслуженный разработчик
Сообщения: 1738
Зарегистрирован: 05 июн 2006, 16:19

Сообщение WildSery » 25 дек 2007, 17:41

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

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 25 дек 2007, 18:17

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

Attid
Спец
Сообщения: 377
Зарегистрирован: 14 ноя 2006, 09:58

Сообщение Attid » 27 дек 2007, 12:21

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

KKomov
Сообщения: 14
Зарегистрирован: 20 дек 2007, 17:30

Сообщение KKomov » 27 дек 2007, 16:31

Attid писал(а):
KKomov писал(а):Только вот нужен тип variant, а есть ли такой в IB/FB?
есть =) varchar называется хрини хоть строки хоть даты хоть числа =)
Так-так, это м.б. решение. Если сервер IB/FB позволяет кастовать любой тип в VARCHAR, то со вставкой в историю проблем не будет.

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

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

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

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

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

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

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

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 27 дек 2007, 18:12

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

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

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

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

Ответить