GoldDragon
Данные в базе можно ртазделить на 3 категории:
(1). Медленно меняющиеся или вообще не меняющиеся (например адрес объекта).
(2). В среднем темпе меняющиеся (раз или 2 в месяц).
(3). Быстро меняющиеся (5-10 раз в неделю).

Бросайте все это. Данные можно разделить только на 2 категории: "грязные данные", "чистые данные". Между ними стоит а-ля брендмауэр, который решает пускать-непускать. Во многих системах это называется Учетом или Posting. Вся отчетность и принятие решений только на чистых данных. Лучше потратить время на решение проблем планирования, прогноза, расчеты, usability системы и ,в конце концов, логику этого брендмауэра ,чем вычислять периодичность изменения данных.

я хотел сказать, что заданные тобой вопросы возникают когда данные свалены в одну кучу. Поэтому когда человек видит в отчете совсем не ту цифру, которую он видел вчера - задает вопрос. Избавься от этой проблемы и не будет подобных вопросов.

YBW iscrafmя хотел сказать, что заданные тобой вопросы возникают когда данные свалены в одну кучу. Поэтому когда человек видит в отчете совсем не ту цифру, которую он видел вчера - задает вопрос. Избавься от этой проблемы и не будет подобных вопросов.

так просто???

а что можно сделать, чтобы избавиться от подобных ответов?

YBW, всегда, когда возникают подобные вопросы (постоянная фиксация и хранение изменений) нужно узнавать причину их возникновения. Логирование при любой правке не самое эффективное решение. Поэтому в большинстве случаев помогает устранение самого вопроса.
А если уж влез, то и на твой вопрос ответ - пойти смотреть сериалы.

GoldDragoniscrafm,
Спасибо тебе за ответы, но я действительно не догоняю, что ты имеешь ввиду. Что именно убрать? Какую проблему?
Сидит себе секретарша на телефоне, одним ухом слушает клиента, одним глазаом на телефон, другим на клавиатуру и печатает, то что клиент говорит. После этого - эта же секретарша или другая, связывается с агентом, который должен что-то сделать, неважно что и всё что говорилось между ними тоже заносится в базу данных. Короче, много чего заносится в базу данных и часто это происходит в быстром темпе. И как бы это секретарша не была бы квалифицирована, могут быть ошибки, которые будут исправляться. Изменения в цене на дом тоже могут быть. Многое чего может быть.

А ты говоришь, что журнал изменений не нужен, если я правильно тебя понял. А что вместо?
я тебе предлагаю решить эту задачу через интерфейсную таблицу и процедуру постинга.
У тебя есть каталог недвижимости и есть интерфейсная таблица операций с этим каталогом. Между ними находится процедура, которая в зависимости от операции и разных дополнительных условий изменяет каталог. При этом записи в интерфейсной таблице и являются историей (журналом изменений). Введенные данные могут быть приняты и ,соответственно, на их основании выполняется модификация текущего состояния картотеки или отменены, если запись картотеки по каким-то причинам нельзя уже модифицировать. Интерфейсная таблица имеет туже структуру, что и рабочая картотека. Связываются по ID. Если в интерфейсной таблице ID пустое, то это новая запись. Также есть дата актуальности. Это достаточно простое в реализации решение, то оно избавит тебя от многих непредвиденных ситуаций, которые могут возникнуть, если ты будешь выстраивать схему от рабочей картотеки и где-то в тригерах анализировать зачем изменили значение того или иного поля и можно ли было это делать. А если можно и тригер ошибся или логикой пока не предусмотрена возникшая ситуация, а пользователь ввел кучу данных, которые в момент отката бесследно пропали? А так ты получаешь простой интерфейс и простой способ мониторинга изменений состояния картотеки недвижимости. Понятно, что история объекта - это набор записей в интерфейсной таблице связанный с карточкой объекта недвижимости по ID. Отчетность тоже простая. Для большего usabilyty можно поработать над мастером ввода данных, чтобы он предоставлял пользователю только те поля ввода, которые нужны для отражения в системе требуемых изменений.