Как сделать массовые изменения в проверенной таблице?

Question

У меня есть система, где все изменения в бизнес-объектах должны проверяться. Таким образом, у сущности MyEntity есть свойство Number, и при изменении этого поля система оставляет одну исходную запись и создает другую запись с новым числовым значением и отмечает исходную запись в архиве, Number является , а не первичным ключом. Также имеется поле Version для отслеживания каждой версии объекта и поле Id для отслеживания идентичности объекта в нескольких версиях. Все идет нормально.

Если вы удаляете сущность, система не удаляет запись, а просто помечает ее как удаленная . Все идет нормально.

Вот проблема. Теперь у клиента есть несколько объектов в списке, и могут быть пробелы:

Item 1
Item 2
Item 3
Item 5
Item 6
...
Item 10

Они хотят иметь возможность делать две новые вещи:

1. Вставьте элемент с номером 5 и сдвиньте все последующие элементы на номер (5 -> 6, 6 -> 7 и т. Д.)
2. Сверните пробелы в элементах, например, перенумеруйте 5 -> 4 и сдвиньте все последующие элементы на число.

Это кажется мне очень неприятным, потому что обычно любое изменение числа нужно проверять, поэтому я не могу просто так изменить все числа в целом. (И это еще более сложно, потому что каждое изменение должно быть одобрено супервизором, и изменения могут быть восстановлены до предыдущего состояния аудита.)

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

Answer 1

Я никогда по-настоящему не решал эту проблему полностью удовлетворительным способом, но мы справились с этим, внедрив специальный режим, доступный только для супер-администратора, где аудит отключен для этого вида операции по смене идентификации, на том основании, что1001 *, хотя он и не является первичным ключом, является важным пользовательским ключом, и если вы его измените, вы меняете идентификацию объекта на новую вещь, которая начинается с чистого листа.Не идеальный, но разумный компромисс.

Answer 2

У меня есть система, где все изменения в бизнес-объектах должны проверяться.

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

Если ваш аргумент сталкивается с сопротивлением,Я бы попытался переименовать Number или OrderByNumber во что-то смешное, но очевидное.Это заставит людей улыбаться, и они увидят смысл: NotABusinessConcernNumberButUIElementNumberUsedForVisualOrdering .

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