Архитектура для аудитов

Question

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

В каждой ревизии может быть от 0 до 60 уникальных ссылок. Я сделаю справочную таблицу для хранения каждой цитаты регулирования, но как мне создать центральную таблицу, чтобы столбец «цитата» мог иметь или любое количество других комбинаций?

Answer 1

Обычно я стараюсь хранить информацию об аудиторе в одной таблице. Для того, чтобы сделать это, я иду что-то вроде этого:

TABLE: Audit 
**Id** (PK) 
**EntityClass** (the Class, or type, or whatever you want to identify your entities by) 
**EntityId** (the id of the entity in it's own table) 
**PropertyChanged** (the name of the property of the entity that changed) 
**OldValue** (the old value of the property) 
**NewValue** (the revised value of the property) 
**TimeStamp** (moment of the revision) 
**RevisionType** (transaction type: Insert, Update, Delete) 

Это самая простая схема, вы можете построить на том, что с дополнительными столбцами, если вы хотите.

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

Answer 2

В этом примере я предполагаю, что, ссылаясь на конкретный номер, если есть цитаты, существует или может быть - таксономическая таблица, содержащая 60 определений или ссылок, по одному для каждого типа цитирования.

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

create table Audits(
    ID   int identity(1, 1), 
    Started  date, 
    Completed date, 
    CustomerID int, 
    AuditorID int, -- More than one possible auditor? Normalize. 
    VerifierID int, 
    Details  ..., 
    constraint PK_Audits primary key(ID), 
    constraint FK_Audits_Customer(foreign key(CustomerID) 
     references Customers(ID), 
    constraint FK_Audits_Auditor(foreign key(AuditorID) 
     references Auditors(ID), 
    constraint FK_Audits_Verifier(foreign key(VerifierID) 
     references Auditors(ID), 
    constraint CK_Audits_Auditor_Verifier check(AuditorID <> VerifierID) 
); 

AuditCitations таблица содержит каждую цитату для каждого аудита, одну запись для каждой ссылки. Обратите внимание, что ПК будет препятствовать тому, чтобы один и тот же аудит имел более одной ссылки на одну и ту же цитату (если, конечно, это ваше правило).

create table AuditCitations(
    AuditID  int, 
    CitID  int, 
    Details  ..., 
    constraint FK_AuditCitations_Audit(foreign key(AuditID) 
     references Audits(ID), 
    constraint FK_AuditCitations_Citation(foreign key(CitID) 
     references Citations(ID), 
    constraint PK_AuditCitations primary key(AuditID, CitID) 
); 

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