Речь идет о переодических реквизитах или об аудите действий
пользователей? Или обо всем в одном флаконе?
Кажется надо все в одном флаконе.
Я у себя разделил в конце концов. Хоть и есть в обеих случаях что-то общее,
но суть разная. И ежели в одной части чего-то менять/дописывать надо, то
приходится делать это с учетом другой части. Геморой вообщем. Имхо, пусть уж
лучше где-то данные дублируются.
Аудит, протоколирование (логи изменения) можно вешать на тригерах и писать
все в одну таблицу, типа Вася добавил (удалил, изменил) запись, это
просто.
Ок.
Мне надо щас разрабатывать механизм которы позволял получать версию записи
на определенном этапе (во времени, или например по стадии продвижения
записи (например документ) по некому бизнесс процессу).
От дополнительных табличек с историей значения каждого реквизита я
отказался. Уж больно мудреные SQL получаются. Сейчас храню версии записи с
диапазоном дат, указывающим период ее актуальности. Соответственно любое
поле может работать как переодический реквизит. Запросы сильно не
усложняются и не замедляются. Выглядят так примерно:
Select D.Num, C.Address
from Doc D
Inner Join Clients C on D.IdClient = C.IdClient and D.Dat between C.StartDt
and C.EndDt
Соответственно C.Address - переодический реквизит. Ну а в программе
реализована возможность как редактирования версии записи на определенную
дату, так и добавления новой версии на новый период.
У Ded-a более легкий вариант для Select-ов. У него в документе хранится
ссылка на конкретную версию записи. То бишь ему between в join-е не нужен. Я
от этого варианта отказался, так как больше проблем при изменении периода
актуальности версии записи.
With b/r. Gleb.
