Это так, досужие размышления.

Значит, начнем...

Имеется любая база. Хочется в этой базе хранить историю изменений, с информацией о времени и пользователе, эти изменения сделавшим.

Для чего? А черт ее знает. Пока болею, работать не могу, а в голову всякие мысли нехорошие лезут :) М.б. хотя бы для того, чтоб пользователь мог посмотреть хронологию изменения любой записи, например, справочника.
Например, такая организации программы даст возможность посмотреть запись прихода годичной давности и увидеть в этой записи наименование контрагенда до его возможного переименования. Позволит вносить изменения в справочники. Ну и т.п.

Какие способы вижу?

Способ номер раз:
Во все таблицы добавляем поля TimeChange, Changer.
+ Максимально быстрая возможность получить состояние базы на любой момент времени.
- Хранится куча лишней информации. После изменения одной буковки любого поля создается копия всей записи

Способ номер два:
Делаем отдельную таблицу c полями
TimeChange, Changer, TypeValue, OldValue
и складываем туда все изменения.
+ Можно хранить только обновленные значения.
- Восстановить содержимое любой записи дело хоть и возможное, но дюже неудобной. Получить, скажем какой нибудь отчет за прошедшую дату вообще представляется почти фантастическим занятием.

Вот.

Поделитесь, пожалуйста, опытом. Кто-нибудь это делал в утилитарном виде (а не как "заплатка" для той или иной формочки)? Зачем? Каким способом?

?
Может, ты и прав.
А с помощью этих лога можно поднять состояние на такой-то момент времени?
А в случае с мдб?

Спасибо :)

2Темный\r
Еще раз спасибо.\r
\r
2Александр Шкуренко\r
> Если с SQL Servr\'ом все-же проще, триггеры могут помочь\r
Обождите. Может, это я поторопился, но мне показалось со слов Темного,\r
что "включение лога" само по себе снимает вопрос, без дополнительных \r
телодвижений. Сейчас хожу по ссылкам Сенина Виктора, ищу похожий\r
вопрос.\r
\r
Хаха 2 раза:\r
\r
\r
Jimmy\r
Member\r
\r
Откуда: г.Москва\r
Сообщений: 1383 \r
Для более-менее адекватного ответа нужно в вопросе указать, как будут использоваться эти данные. Например, можно понять так:\r
\r
1. Для архива, использоваться крайне редко в специфических ситуациях, скорострельность в данном случае особой роли не играет\r
\r
2. Будет использоваться для онлайнового анализа (OLAP)\r
\r
3. Будет использоваться в транзакционной БД для построения временно-зависимых наборов данных. В качестве исторических атрибутов будут использованны несколько полей (не все) таблицы. Скорострельность имеет большое значение.\r
\r
Ну и ответы:\r
\r
1. Используй архивную БД\r
\r
2. Используй ROLAP схему хранения + MS Analysis Service + OLAP клиента\r
\r
3. А здесь уже есть варианты:\r
\r
-- при обновлении записи не переписывать ее, а добавлять в ту-же таблицу + дату обновления + признак актуальности записи (чтобы избежать анализа дат при запросе)\r
\r
-- хранить исторические атрибуты в виде отдельной таблицы с признаком актуальности и датой обновления\r
\r
Недостатки и достоинства сам определи для твоего конкретного случая. \r
Это отсюда. Там же еще одна ссылка, подтверждающай эти слова.\r
\r
> Чем лечишься, то? Клюквой наверно \r
\r
Ею, млин \r
\r
2ЛП\r
Да, собственно об 1С-е я и думал, когда этот вопрос вырос. Уж больно красиво там задумано это самое журналирование изменений и разграничение прав. Именно не как временная мера для одной-другой формы, а на уровне ядра программы. Тоже такую хочу. Тем паче в 1С это сделано на основе dbf.\r
\r
2Сенин Виктор\r
Спасибо. Более-менее ответил в части к Александру Шкуренко.