Хранение метаданных о строке со строкой базы данных? - PullRequest
0 голосов
/ 01 сентября 2011

Каковы оптимальные методы хранения метаданных о строке с строке?

Возьмите пример межбанковского финансового перевода.Transfer может выглядеть следующим образом:

CREATE TABLE Transfers (
   TransferID int,
   FromTransit varchar(10),
   FromBranch varchar(10),
   FromAccount varchar(50),
   ToTransit varchar(10),
   ToBranch varchar(10),
   ToAccount varchar(50),
   Amount money,
   Status varchar(50));

Но теперь, конечно, люди захотят видеть метаданные:

ALTER TABLE Transfers 
ADD
    CreatedDate datetime,
    LastModifiedDate datetime,
    CreatedByUsername varchar(50),
    CreatedByFullname varchar(200),
    CreatedByWorkstation varchar(50),

    VoidedDate datetime NULL,
    VoidedByUsername datetime NULL,
    VoidedByFullname datetime NULL,
    VoidApprovedBySupervisorUsername varchar(50) NULL,
    VoidApprovedBySupervisorFullname varchar(200) NULL,
    VoidApprovedBySupervisorWorkstation varchar(50) NULL,

    SentDate datetime NULL, 
    SentByUsername varchar(50) NULL,
    SentByFullname varchar(50) NULL,
    SentByWorkstation varchar(50) NULL,
    SendApprovedBySupervisorUsername varchar(50) NULL,
    SendApprovedBySupervisorFullname varchar(50) NULL,
    SendApprovedBySupervisorWorkstation varchar(50) NULL,
    SendConfirmationNumber varchar(50) NULL,
    SentToRemoteMachineName varchar(50) NULL,

    ReceivedDate datetime NULL, 
    ReceivedConfirmationNumber varchar(50) NULL,
    ReceivedToRemoteMachineName varchar(50) NULL,
    ReceivedByUsername varchar(50) NULL,
    ReceivedByFullname varchar(50) NULL,
    ReceivedByWorkstation varchar(50) NULL,
    ReceiveApprovedBySupervisorUsername varchar(50) NULL,
    ReceiveApprovedBySupervisorFullname varchar(50) NULL,
    ReceivedApprovedBySupervisorWorkstation varchar(50) NULL,

    ReceivedCheckedBySupervisorUsername varchar(50) NULL,
    ReceivedCheckedBySupervisorFullname varchar(50) NULL,
    ReceivedCheckedBySupervisorWorkstation varchar(50) NULL
)

Это все четко определенные значения, которыевсе они появятся на бумажном носителе, связанном с передачей.

У нас уже есть журнал аудита изменений в таблицах, но это не может отловить что-то вроде:

UPDATE Transfers SET Status = 'TransferStatus_Received'
WHERE TransferID = 6744891

Это отловит имя пользователя , полное имя и имя машины человека, который внес изменение;но он не может знать имя руководителя, который был за плечом человека, чтобы ввести свои учетные данные, чтобы "разрешить" перевод, который будет получен.

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

Это лучший метод?

Ответы [ 2 ]

2 голосов
/ 01 сентября 2011

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

Вместо этого вы должны запретить обновления;все изменения должны быть вставлены.У всех таблиц должен быть индексированный последовательный столбец FK, и все объединения находятся на Max(seq).Это означает, что вы выполняете все транзакции с последними данными, но у вас есть постоянная запись каждой транзакции в этих таблицах.

Редактировать: Если вы спрашиваете, нужно ли добавлять столбцы аудита в исходную таблицу, тозависит от того, являются ли столбцы аудита редкими или обнуляемыми.Судя по вашим комментариям, это так.

В этом случае вы должны создать отдельные таблицы для каждой группы атрибутов аудита, которые могут иметь значение nullable, и выполнить внешнее соединение этих таблиц, соединяясь с последовательным столбцом исходной базы данных.Это означает, что вы можете добавлять или удалять таблицы аудита по своему усмотрению, не затрагивая таблицу данных.Что-то вроде:

SELECT t.transferID, t.money, u.Date, u.workstation, s.name, ...
FROM Transfers t
    LEFT OUTER JOIN Users u ON u.seq = t.seq
    LEFT OUTER JOIN Supervisors s ON s.seq = t.seq
WHERE t.seq = (SELECT Max(seq) FROM Transfers WHERE whatever)

Вы можете создать представление или хранимую процедуру, которая сохраняет Max(seq), если вам необходимо повторно использовать ее в транзакции.

1 голос
/ 01 сентября 2011

Я не знаю много о SQL Server, но когда сталкиваюсь с таким в сценарии Oracle, я склонен использовать триггеры (вставка / обновление / удаление), которые переносят всю строку (до и после) в «архив / аудит» добавьте в таблицу и добавьте все «метаданные», которые они хотят записать вместе с ним ... таким образом, моя модель данных, ориентированная на приложения, не будет получена в отношении приложений / SP и т. д., и ни одно приложение / пользователь не имеет доступа к этой конфиденциальной информации ведения журнала / аудита. ..

...