|
|
|
Реализация "отложенного" изменения, требующего утверждения
|
|||
|---|---|---|---|
|
#18+
Здравствуйте, возникла задача реализовать следующий функционал: Пользователь заходит в форму редактирования какой-либо сущности, делает необходимые ему изменения, нажимает "Save". Но изменения пользователя должны вступить в силу только после того, как они утверждены третьим лицом, причём необходимо хранить всю историю изменений. В голове довольно много вариантов, но хочется узнать мнение других людей, возможные рекоммендации и "best practice" для данной задачи. Любые высказывания приветствуются! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2008, 23:51 |
|
||
|
Реализация "отложенного" изменения, требующего утверждения
|
|||
|---|---|---|---|
|
#18+
Добавлю исходны данных.... Необходимо фиксировать не просто одного экземпляра сущности, а так же его дочерних (более чем на один уровень, но не всех), т.е. целой ветки. Но при этом не хочется копировать всю ветку. Например, такой вариант лёгок (история изменения паспортов) ID ФИО Текущий паспорт1 Иванов И. И. 102 Петров П. П. 12 ID Ссылка на человека Серия Номер10 1 111 22211 2 ааа ббб12 2 777 777 Т.е. у втрого человека было два паспотра, а сейчас текущий под идентификатором 12. Мы повторяем полностью экземпляр паспотра (даже если бы вдруг какие-то атрибуты оставались те же) Большая проблема, когда у нас есть дочерние сущности у паспотрта (которые ссылаются на него как он ссылается на человека) особенно если многие к одному. Т.е. при редактировании какого-то экземпляра на одном уровне у нас есть два варианта 1) копировать всю ветку (считать как одной большой составной сущностью) ради изменения одного атрибута 2) вести подобную историю отдельно для каждого уровня сущностей Первый варинат смущает копирование целой ветки при изменении одного листика (но информация должна быть сохранена, потому что на основании значений на тот времени зависит бизнесс-логика) Второй вариант плох тем что изменения для каждого уровня независимы... Т.е. на одном уровне мы сделали 3 изменения, на другом 5ть, но что и с чем мы меняли понять будет не возможно (мы не можем принять 5ое изменение на уровне ниже, если оно не соответвует 2ому изменению на родительском уровне). Т. е. Я представляю это дело как заменя полностью ветки. Как заполнение совершенно новой какой-то абстрактной карточки или анкеты в которой можно указать соовершенно другие значения и мы храним оба бланка. Надеюсь не слишком загрузил мозги, заранее спасибо от нас обоих :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2008, 00:21 |
|
||
|
Реализация "отложенного" изменения, требующего утверждения
|
|||
|---|---|---|---|
|
#18+
вариант, заимствованный из классификатора адресов - хранение исторических записей для каждой сущности, например, указанный пример с паспортом. Для начала надо определиться - будет ли нужен историзм или достаточно последнего состояния? Если историзм в текущей работе не нужен, а только логи изменений, то нужно составить таблицы для ведения логов изменений нужных полей в рабочих таблицах - это аудит "кто когда и что менял", - автоматизировать этот механизм не проблема, основной работе мешать не будет но собирать в таком случае данные на произвольный момент времени - трудоемко. Когда нужен произвольный равноценный доступ, то без полноправного хранения временных копий эффективной работы с данными вряд ли получится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2008, 01:19 |
|
||
|
Реализация "отложенного" изменения, требующего утверждения
|
|||
|---|---|---|---|
|
#18+
BenettonЗдравствуйте, возникла задача реализовать следующий функционал: Пользователь заходит в форму редактирования какой-либо сущности, делает необходимые ему изменения, нажимает "Save". Но изменения пользователя должны вступить в силу только после того, как они утверждены третьим лицом, причём необходимо хранить всю историю изменений. В голове довольно много вариантов, но хочется узнать мнение других людей, возможные рекоммендации и "best practice" для данной задачи. Любые высказывания приветствуются! Может, задача из разряда "управление документооборотом"? Самое простое: организовать данные в виде дерева, и опеределять "готовность" по статусу головной записи (ключевой), например, специальное поле, указывающее на стадию подготовки документа, и использовать согласно этому полю. Так избегаем дублирования таблиц, здесь важно лишь в каждой рабочей выборке данных соотноситься со статусным полем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2008, 01:30 |
|
||
|
Реализация "отложенного" изменения, требующего утверждения
|
|||
|---|---|---|---|
|
#18+
Самое простое - добавить в каждую таблицу поля Version int, VersionDate datetime и Actual bit. И колбасить изменения любой строки таблицы вставкой новой версии строки. Когда добрый дядя поставит на ей Actual=1 - она станет активной версией. Естественно, это не добавит быстродействия при выборке... но ежели интенсивность вставок невысока, то правильно построенный кластерный индекс спасет. >>Но при этом не хочется копировать всю ветку. Не копируй. Какие проблемы? >>Т.е. на одном уровне мы сделали 3 изменения, на другом 5ть, но что и с чем мы меняли понять будет не возможно (мы не можем принять 5ое изменение на уровне ниже, если оно не соответвует 2ому изменению на родительском уровне). Не пудри себе (и другим) мозги. Изменения делаются в рамках одной версии. Версия выбирается в момент начала измения - все изменения можно установить сравнив две версии. >>но что и с чем мы меняли понять будет не возможно Храни историю актуализации и запрети изменения всех актуализированных версий, даже после того как актуализация будет передана другой версии. >>мы не можем принять 5ое изменение на уровне ниже, если оно не соответвует 2ому изменению на родительском уровне Если независимое изменение атрибутов недопустимо - значит придется копировать ВСЕ при создании новой версии. Модератор: Тема перенесена из форума "Microsoft SQL Server". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2008, 08:07 |
|
||
|
Реализация "отложенного" изменения, требующего утверждения
|
|||
|---|---|---|---|
|
#18+
BenettonПользователь заходит в форму редактирования какой-либо сущности, делает необходимые ему изменения, нажимает "Save". ... Раз такое дело, пользователь перед редактированим сущности должен создать её копию, внести изменения и сохранить их в копию. Потом третье лицо в процессе подтвержения переместит копию сущности в хранилище. Очевидно, копия должна иметь связь с оригиналом (оригинал может отсутствовать в случае создания новой сущности). Для поддержки операции удаления копия должна иметь признак "Удалить". (в случае удаления полная копия по большому счёту не нужна, достаточно иметь только связь с оригиналом, но тогда логика усложняется). В зависимости от стратегии блокирования изменяемых объектов оригинал может иметь связь с блокировкой. Перемещение копии зависит от реализации основного хранилища. В общем случае выполняется операция создания/изменения/удаления сущности в хранилище и удаление копии. BenettonЛюбые высказывания приветствуются! Это особенно понравилось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2008, 13:45 |
|
||
|
Реализация "отложенного" изменения, требующего утверждения
|
|||
|---|---|---|---|
|
#18+
Спасибо всем участникам дискуссии, 1. aleks2 > Если независимое изменение атрибутов недопустимо - значит придется копировать ВСЕ при создании новой версии. -- Так и решено делать 2. vino > Может, задача из разряда "управление документооборотом"? Задача в конечном счёте упирается в полную "версионность", так что аналогии провести вполне возможно. 3. expla > Это особенно понравилось :) - 2 головы хорошо, а свежие мысли всегда приветствуются! Особенно хочется выделить ответ aleks2 - большое спасибо за трезвые рассуждения) ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2008, 03:08 |
|
||
|
Реализация "отложенного" изменения, требующего утверждения
|
|||
|---|---|---|---|
|
#18+
Benetton, если поможет: Мой вариант ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2008, 16:53 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=94&tid=1543501]: |
0ms |
get settings: |
7ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
39ms |
get topic data: |
46ms |
get forum data: |
4ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
| others: | 218ms |
| total: | 387ms |

| 0 / 0 |
