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

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

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

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

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

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

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

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

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

использовать, имхо, можно или первый или второй вариант. Во втором, имхо опять же, проще необходимая отчетность получается и им проще управлять.

а...ты ж не забывай, что пишутся только изменения. Если текст менялся, то при любом раскладе его нужно записать в базу. А не менялся, то он и не будет место занимать.

если тупо в лоб, то примерно это имелось ввиду в процедуре постинга:


т.е. неизменяемые поля заполнять не нужно когда вводится информация.

ModelRА как тогда занулить поле? Старое 'xxx' , новое NULL. В источнике придется иметь флаги изменения для каждого поля. В источник также нужно той же транзакцией вернуть временнУю метку/последовательный номер.
Т.е по сравнению с простой исторической таблицей технология несколько сложнее.
я бы так сказал. Это несколько может и сложнее в плане интерфейса, но совсем немного.
А зачем метки возвращать?

GoldDragon AlexTheRaven
Можно хранить классы в структуре EAV. Тогда всё получается само собой, достаточно в таблице значений атрибутов добавить поля "актуальность" и "дата создания", а вместо изменения значения добавлять новое, а старое объявлять неактуальным. Делал, работает, логика не очень сложная.

И что это за зверь такой? :) И где его найти можно?
Это такой принцип построения хранилища данных. Запусти в гугле EAV/CR, повываливается много.