Comments 8
UFO just landed and posted this here
Хм. Ну это понятно. SQL логи и т.д. Но давайте воспринимать БД не как SQL ориентированную а как абстрактное хранилище. В это случаем какой то механизм (ну допустим ActiveRecord) преобразует данные в объекты. А бизнес логика при изменении объектов способна отследить какие именно параметры объектов изменены и сохранить это в удобном виде, но не важно куда — в БД или файлы. Важно то что по этим данным можно установить какие параметры объектов менялись и когда, и, при желании, как воспроизвести историю объекта, так и откатиться на определенную позицию. Что то типа контроля версий объектов модели.
> ответы, рекомендации и споры которых генерируют знания.
правильнее будет " ответы, рекомендации и споры которых генерируют драму." :)
правильнее будет " ответы, рекомендации и споры которых генерируют драму." :)
Я не знаю как это в «корпоративных системах», но у меня объекты типа ActiveRecord (точнее их аналоги в собственном фреймворке) имеют режим сохранения предыдущего состояния при вызове метода update() в специальном хранилище, с указанием типа измененного объекта, измененных полей, их предыдущих состояний и того кто эти изменения сделал.
Модифицировать ActiveRecord или вписать в дерево наследования соответсвующих класс — сложности не представляет. Как это будет по скорости при нагрузках — не знаю, у меня не корпоративные системы :)
Модифицировать ActiveRecord или вписать в дерево наследования соответсвующих класс — сложности не представляет. Как это будет по скорости при нагрузках — не знаю, у меня не корпоративные системы :)
У меня нет ActiveRecord, это я для примера привел. За предметную область у меня отвечает некоторый набор классов ValueObject, а манипуляции с базой идут через подобие шлюза. Отследить изменяемые поля в объектах — это не большая трудность. В основном меня заботит именно хранение изменений. Вы пишите про «специальное хранилище» — что под этим подразумевается? Я где то на хабре видел что хранение изменений ведется в таблицах, идентичных по структуре, НО мне кажется этот вариант нерациональным в связи с избыточностью и трудоемкостью, однако есть плюс — большая скорость и упорядоченность.
От идентичных по структуре таблиц я отказался из тех же соображений.
Хранилище имеет примерно такую структуру:
— ID
— Тип объекта
— Имя поля
— Старое значение
— Дата + время изменения
— Кто изменил
Поле «Тип объекта» содержит внутренне имя типа измененного объекта или (если так проще) имя измененной таблицы.
Все остальное вроде понятно.
Минусы подхода — если в объекте 20 полей и все они поменялись вы получите 20 insert'тов.
Плюсы — можно делать выборку по измененным полям.
Вариант обхода данного минуса (с потерей плюса): хранить изменения не для каждого поля, а для всего объекта в виде сериализованного JSON-объекта в одном BLOB'е. Быстро сохранить, быстро восстановить, и всего лишь один дополнительный insert на объект.
Хранилище имеет примерно такую структуру:
— ID
— Тип объекта
— Имя поля
— Старое значение
— Дата + время изменения
— Кто изменил
Поле «Тип объекта» содержит внутренне имя типа измененного объекта или (если так проще) имя измененной таблицы.
Все остальное вроде понятно.
Минусы подхода — если в объекте 20 полей и все они поменялись вы получите 20 insert'тов.
Плюсы — можно делать выборку по измененным полям.
Вариант обхода данного минуса (с потерей плюса): хранить изменения не для каждого поля, а для всего объекта в виде сериализованного JSON-объекта в одном BLOB'е. Быстро сохранить, быстро восстановить, и всего лишь один дополнительный insert на объект.
Sign up to leave a comment.
Логирование изменений объектов модели