шаблон проектирования модели данных, который хранит изменения данных, пока не будет авторизован другим пользователем - PullRequest
3 голосов
/ 09 мая 2011

Существует ли шаблон проектирования, который следует учитывать при построении модели данных для банковского приложения, для которого требуется, чтобы изменения данных проходили уровень авторизации?

Например, если admin1 меняет номер телефона для customer1, изменение не должно вступать в силу, пока admin2 не авторизует его.

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

Ответы [ 3 ]

1 голос
/ 09 мая 2011

Я не знаю ни одного шаблона проектирования, но думаю, у меня может быть другая идея для вас -
есть только одна другая таблица, называемая 'Pending_Changes' со столбцами 'Table_Identifier', 'Column_Identifier' 'Record_Identifier' и 'New_Value'.
Каждая строка будет представлять одно изменение столбца для некоторой записи в некоторой таблице.
Например, строка со значениями ('Customers', 'Phone_Number', '12345', '077-4453432') будет использоваться для представления изменения в номере телефона клиента 12345.
Пара недостатков этого метода заключается в том, что -
1. все ваши таблицы должны иметь одно поле ID
2. изменение одной записи может занимать несколько строк в таблице PendingChanges, поскольку оно сохраняет строку для каждого измененного значения столбца.

С другой стороны, он достаточно расширяемый и достаточно простой в обслуживании.

1 голос
/ 09 мая 2011

Это прекрасно работает, когда у вас мало таблиц, но будет громоздким при увеличении таблиц

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

например. У вас могут быть такие таблицы, как: AuditTables, AuditColumns, AuditChanges, AuditChangesDetails и т. Д., И вы можете хранить все необходимые изменения в этой модели, а не создавать временную таблицу, соответствующую «живой» таблице.

0 голосов
/ 09 мая 2011

Я разработал что-то вроде этого, и вот суть этого;

  1. Я создаю зеркальную таблицу для каждой таблицы, для которой требуется контроль версий на уровне строк. Допустим, у вас есть таблица CUSTOMER. Ваша таблица контроля версий зеркала будет VER_CUSTOMER Каждая таблица, в которой я хочу иметь контроль версий на уровне строк, имеет столбец с именем RECORD_ID (GUID)
  2. Когда запись вставляется в эту таблицу, я генерирую новый GUID и заполняю это поле. Новая запись также вставляется в таблицу VER_CUSTOMER с RECORD_ID как добавляется к естественному PK таблицы. Когда запись обновляется, я снова генерирую новый GUID. Заполните RECORD_ID с этим новым GUID. Обновленная запись также отправляется в таблицу VER_CUSTOMER.
  3. Когда запись удалена, я отмечаю запись в таблице CUSTOMER как DELETED (физически не удаляю запись). У меня есть столбец IS_DELETED на каждой таблице. Я установил для этого столбца значение ИСТИНА при попытке удаления записи. Снова копия удаленной записи также попадает в таблицу VER_CUSTOMER.
  4. Таким образом, для каждой транзакции, которая у вас есть в этой таблице, у вас есть соответствующая запись в таблице VER_CUSTOMER с RECORD_ID и естественным PK таблицы в качестве PK. Например, если PK таблицы CUSTOMER имеет значение CUST_ID. PK VER_CUSTOMER будет составным CUST_ID и RECORD_ID.

Надеюсь, это поможет ...

...