Третья часть - версионность записей и история их изменений
Некоторые сервера используют версионность внутри для реализации параллельного чтения-записи данных, сохраняя старые версии измененных записей, если есть транзакция которой они еще нужны на предмет чтения.
Но дело в том, что часто версионность и история изменений нужна и на пользовательском уровне. Даже реализовав систему разграничения доступа к записям и разрешив менять записи только строго определенным пользователям - у них возникает вопрос "А какое значение в этой записи было вчера?". Поэтому приходится реализовывать историю изменений и хранение версий самому, как минимум частично повторяя существующую функциональность сервера.
А еще есть такая вещь, как изменения задним числом в бухгалтерии. Мрачная печаль, хотелось бы заметить. Изменение одной записи иногда тянет за собой каскад изменений других и методику адекватной
В 90-ом году написал на Clipper 5 движок, который реализовывал обе задачи - т.е. журналирование и была возможна корректировка записей в двух режимах - внесение очередных изменений (по ним можно было вытаскивать историю) и исправление ошибок задним числом. Когда выпустил бету (писалось всё под конкретную аппликуху), решил, что пойду повешусь от полноты пережитых чувств. Релиз так и не был выпущен, в связи с переводом проекта на CodeBase.
адекватной реализации подобного каскада с расчетом переходов(корректировочных проводок, прокладываемых сейчас для учета исправления ошибки несколько месяцев назад) между двумя деревьями зависимых записей (тем, которое было, и исправленным) я до сих пор представляю с трудом. Максимум, что мне приходит в голову, это представить все это дело как многомерный массив, индексами в котором будут последовательности аналитических кодов, рассчитать дважды и вычесть один массив из другого. Так вот, логическим было показана, что задача в общем виде не решабельна. Есть несколько различных методов - их приходится отруливать вручную на основе свободного волеизлеяния бухгалтера.
no subject
Некоторые сервера используют версионность внутри для реализации параллельного чтения-записи
данных, сохраняя старые версии измененных записей, если есть транзакция которой они еще
нужны на предмет чтения.
Но дело в том, что часто версионность и история изменений нужна и на пользовательском уровне.
Даже реализовав систему разграничения доступа к записям и разрешив менять записи только строго
определенным пользователям - у них возникает вопрос "А какое значение в этой записи было вчера?".
Поэтому приходится реализовывать историю изменений и хранение версий самому, как минимум частично
повторяя существующую функциональность сервера.
А еще есть такая вещь, как изменения задним числом в бухгалтерии. Мрачная печаль, хотелось бы заметить.
Изменение одной записи иногда тянет за собой каскад изменений других и методику адекватной
В 90-ом году написал на Clipper 5 движок, который реализовывал обе задачи - т.е. журналирование и была возможна корректировка записей в двух режимах - внесение очередных изменений (по ним можно было вытаскивать историю) и исправление ошибок задним числом. Когда выпустил бету (писалось всё под конкретную аппликуху), решил, что пойду повешусь от полноты пережитых чувств.
Релиз так и не был выпущен, в связи с переводом проекта на CodeBase.
адекватной
реализации подобного каскада с расчетом переходов(корректировочных проводок, прокладываемых сейчас
для учета исправления ошибки несколько месяцев назад) между двумя деревьями зависимых записей
(тем, которое было, и исправленным) я до сих пор представляю с трудом. Максимум, что мне приходит в
голову, это представить все это дело как многомерный массив, индексами в котором будут последовательности
аналитических кодов, рассчитать дважды и вычесть один массив из другого.
Так вот, логическим было показана, что задача в общем виде не решабельна. Есть несколько различных методов - их приходится отруливать вручную на основе свободного волеизлеяния бухгалтера.