Я уж про графики и модели не буду - своих хватает.
Я про другое уж :))

LaoxПоддерживаю. Просто аудит изменений без четких ответов на вопрос "Кому это надо и как он это будет этим пользоваться" может принести пользу только в удовлетворении параноидальных наклонностей администратора приложения.
Ну если никто не пользуется, то пусть администратор и страдает, если у него время есть. Главное, что не мешает никому.
А если не только ему нужно - то ответов то немного получается, а точнее всего два:
1. Просто вести лог изменений данных
2. Восстановить или показать данные в разрезе соответствующего процесса

Кому нужно - на это можно и не отвечать, все-равно разницы нет, директору или логисту :)

LaoxНеобходимости в логгировании изменений можно избежать, проектируя изначально доступ операциям, приводящим к изменениям в данных, либо же сами операции. Это конечно значительно сложнее, чем просто вести лог изменений, но с точки зрения функциональности куда эффективнее.
Я что-то не понял смысла фразы.
Вы хотите так спроектировать процессы, чтобы изменений не было? Так чтоли? Нифига себе!!!
Может вы и сумеете, но у меня любые процессы все-равно рано или поздно ведут к изменениям данных. И уж как бы долго к этому не шло, но посмотреть, чего "наменяли", иногда бывает нужно не зависимо от процессов.

guest_20040621Еще раз: нормально спроектированная база данных обязана позволять извлекать состояние объектов базы данных на любую дату.

> Всех/любого объекта?

Да.

Это уж как-то погорячились.
Зачем мне состояние любого объекта? Незачем!
На сколько это увеличит размер БД? В разы!
На сколько это увеличит сложность разработки и все, что из этого вытекает? В десятки раз!!! (потому что через задницу придется лезть к каждому объекту)

Если вам нравится мазохизм - ваш выбор. Мне - нет. (Это даже и не мазохизм - хуже :). Это скорее всего как раз " удовлетворении параноидальных наклонностей администратора приложения " Или точнее - разработчика-маньяка)
Я уж лучше буду иметь возможность в любой момент включить логирование любой таблицы. А если уж какой-то объект будет требовать ведения всей истории, то уж конкретно для него и будет сие сделано.

-- Tygra's --

автор Если данные являются важными и их изменение критично для бизнеса, то тут лучше не логировать изменения, а использовать подход проводок: т.е. сначала создать намерение, в котором все нужные акторы внесут свои поправки и затем это намерение реализуют в изменение. Опять-таки откатить в таком случае можно.
Мне удалось пояснить вопрос смысл фразы?
Смысл понят так:
В теоретическом плане все красиво.
В практическом - фантастика. Научная, но все же фантастика.
Потому как на каждую таблицу вы не будете навешивать "подход проводок" - либо система умрет, либо бизнес разорится раньше с такой работой системы, а юзеры повесятся, начальник убъет сначала программиста а потом и сам застрелится :))

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

=======

Зачем простое превращать в ужасное? :)

ЗЫ
Тяпница - пора домой почти уже.

-- Tygra's --