powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Реализация "отложенного" изменения, требующего утверждения
8 сообщений из 8, страница 1 из 1
Реализация "отложенного" изменения, требующего утверждения
    #35733753
Фотография Benetton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Здравствуйте,

возникла задача реализовать следующий функционал:

Пользователь заходит в форму редактирования какой-либо сущности, делает необходимые ему изменения, нажимает "Save". Но изменения пользователя должны вступить в силу только после того, как они утверждены третьим лицом, причём необходимо хранить всю историю изменений. В голове довольно много вариантов, но хочется узнать мнение других людей, возможные рекоммендации и "best practice" для данной задачи.

Любые высказывания приветствуются!
...
Рейтинг: 0 / 0
Реализация "отложенного" изменения, требующего утверждения
    #35733774
NIIIK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Добавлю исходны данных....
Необходимо фиксировать не просто одного экземпляра сущности, а так же его дочерних (более чем на один уровень, но не всех), т.е. целой ветки. Но при этом не хочется копировать всю ветку.

Например, такой вариант лёгок (история изменения паспортов)

ID ФИО Текущий паспорт1 Иванов И. И. 102 Петров П. П. 12

ID Ссылка на человека Серия Номер10 1 111 22211 2 ааа ббб12 2 777 777

Т.е. у втрого человека было два паспотра, а сейчас текущий под идентификатором 12.
Мы повторяем полностью экземпляр паспотра (даже если бы вдруг какие-то атрибуты оставались те же)

Большая проблема, когда у нас есть дочерние сущности у паспотрта (которые ссылаются на него как он ссылается на человека) особенно если многие к одному.

Т.е. при редактировании какого-то экземпляра на одном уровне у нас есть два варианта
1) копировать всю ветку (считать как одной большой составной сущностью) ради изменения одного атрибута
2) вести подобную историю отдельно для каждого уровня сущностей

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

Второй вариант плох тем что изменения для каждого уровня независимы...
Т.е. на одном уровне мы сделали 3 изменения, на другом 5ть, но что и с чем мы меняли понять будет не возможно (мы не можем принять 5ое изменение на уровне ниже, если оно не соответвует 2ому изменению на родительском уровне).

Т. е. Я представляю это дело как заменя полностью ветки. Как заполнение совершенно новой какой-то абстрактной карточки или анкеты в которой можно указать соовершенно другие значения и мы храним оба бланка.

Надеюсь не слишком загрузил мозги, заранее спасибо от нас обоих :)
...
Рейтинг: 0 / 0
Реализация "отложенного" изменения, требующего утверждения
    #35733820
vino
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
вариант, заимствованный из классификатора адресов - хранение исторических записей для каждой сущности, например, указанный пример с паспортом.
Для начала надо определиться - будет ли нужен историзм или достаточно последнего состояния?
Если историзм в текущей работе не нужен, а только логи изменений, то нужно составить таблицы для ведения логов изменений нужных полей в рабочих таблицах - это аудит "кто когда и что менял", - автоматизировать этот механизм не проблема, основной работе мешать не будет но собирать в таком случае данные на произвольный момент времени - трудоемко.
Когда нужен произвольный равноценный доступ, то без полноправного хранения временных копий эффективной работы с данными вряд ли получится.
...
Рейтинг: 0 / 0
Реализация "отложенного" изменения, требующего утверждения
    #35733823
vino
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
BenettonЗдравствуйте,

возникла задача реализовать следующий функционал:

Пользователь заходит в форму редактирования какой-либо сущности, делает необходимые ему изменения, нажимает "Save". Но изменения пользователя должны вступить в силу только после того, как они утверждены третьим лицом, причём необходимо хранить всю историю изменений. В голове довольно много вариантов, но хочется узнать мнение других людей, возможные рекоммендации и "best practice" для данной задачи.

Любые высказывания приветствуются!
Может, задача из разряда "управление документооборотом"?
Самое простое: организовать данные в виде дерева, и опеределять "готовность" по статусу головной записи (ключевой), например, специальное поле, указывающее на стадию подготовки документа, и использовать согласно этому полю. Так избегаем дублирования таблиц, здесь важно лишь в каждой рабочей выборке данных соотноситься со статусным полем.
...
Рейтинг: 0 / 0
Реализация "отложенного" изменения, требующего утверждения
    #35733929
aleks2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Самое простое - добавить в каждую таблицу поля Version int, VersionDate datetime и Actual bit.

И колбасить изменения любой строки таблицы вставкой новой версии строки. Когда добрый дядя поставит на ей Actual=1 - она станет активной версией.

Естественно, это не добавит быстродействия при выборке... но ежели интенсивность вставок невысока, то правильно построенный кластерный индекс спасет.

>>Но при этом не хочется копировать всю ветку.
Не копируй. Какие проблемы?

>>Т.е. на одном уровне мы сделали 3 изменения, на другом 5ть, но что и с чем мы меняли понять будет не возможно (мы не можем принять 5ое изменение на уровне ниже, если оно не соответвует 2ому изменению на родительском уровне).
Не пудри себе (и другим) мозги. Изменения делаются в рамках одной версии.
Версия выбирается в момент начала измения - все изменения можно установить сравнив две версии.

>>но что и с чем мы меняли понять будет не возможно
Храни историю актуализации и запрети изменения всех актуализированных версий, даже после того как актуализация будет передана другой версии.

>>мы не можем принять 5ое изменение на уровне ниже, если оно не соответвует 2ому изменению на родительском уровне
Если независимое изменение атрибутов недопустимо - значит придется копировать ВСЕ при создании новой версии.

Модератор: Тема перенесена из форума "Microsoft SQL Server".
...
Рейтинг: 0 / 0
Реализация "отложенного" изменения, требующего утверждения
    #35734800
expla
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
BenettonПользователь заходит в форму редактирования какой-либо сущности, делает необходимые ему изменения, нажимает "Save". ...

Раз такое дело, пользователь перед редактированим сущности должен создать её копию, внести изменения и сохранить их в копию. Потом третье лицо в процессе подтвержения переместит копию сущности в хранилище.

Очевидно, копия должна иметь связь с оригиналом (оригинал может отсутствовать в случае создания новой сущности).
Для поддержки операции удаления копия должна иметь признак "Удалить". (в случае удаления полная копия по большому счёту не нужна, достаточно иметь только связь с оригиналом, но тогда логика усложняется).
В зависимости от стратегии блокирования изменяемых объектов оригинал может иметь связь с блокировкой.

Перемещение копии зависит от реализации основного хранилища. В общем случае выполняется операция создания/изменения/удаления сущности в хранилище и удаление копии.

BenettonЛюбые высказывания приветствуются!

Это особенно понравилось.
...
Рейтинг: 0 / 0
Реализация "отложенного" изменения, требующего утверждения
    #35736294
Фотография Benetton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Спасибо всем участникам дискуссии,

1. aleks2 > Если независимое изменение атрибутов недопустимо - значит придется копировать ВСЕ при создании новой версии.
-- Так и решено делать

2. vino > Может, задача из разряда "управление документооборотом"?
Задача в конечном счёте упирается в полную "версионность", так что аналогии провести вполне возможно.

3. expla > Это особенно понравилось
:) - 2 головы хорошо, а свежие мысли всегда приветствуются!

Особенно хочется выделить ответ aleks2 - большое спасибо за трезвые рассуждения) !
...
Рейтинг: 0 / 0
Реализация "отложенного" изменения, требующего утверждения
    #35741895
Alkatraz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Benetton, если поможет: Мой вариант
...
Рейтинг: 0 / 0
8 сообщений из 8, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Реализация "отложенного" изменения, требующего утверждения
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]