SQL - 審計日誌表設計 - 您更喜歡哪一個？

對於我正在開發的公司正在進行的項目，我們需要爲用戶執行的各種任務（對系統中的表進行的更改）進行審計（存儲日誌）。目前，只有三種不同類型的任務。但這可能會在未來增長。SQL - 審計日誌表設計 - 您更喜歡哪一個？

我對這個建議是下面的架構表的和關係（例如）：

Table AuditLog 
------------------------------ 
Id | PK 
Description 
Created

而且每一項任務：

Table ExampleTaskAuditLog 
------------------------------ 
ExampleTaskId | FK PK 
AuditLogId | FK PK

和：

Table AnotherExampleTaskAuditLog 
------------------------------ 
AnotherExampleTaskId | FK PK 
AuditLogId | FK PK

基本上，我們需要審計的每一種任務，我們都會有一個新的表格來維持這種關係。

什麼其他開發商建議，爲以下：

Table AuditLog 
------------------------------ 
Id (PK) 
Description 
Created 
ExampleTaskId | NULLABLE 
AnotherExampleTaskId | NULLABLE 
Type | (an integer id which indicates whether this is a "example task" or a "another example task").

基本上，如果我們要創建一個日誌「ExampleTask」，我們將在ExampleTaskId字段集合到示例任務的身份和鍵入相應的ExampleTask-enum值。

他建議上表，因爲他在爭論誠信（我認爲很好！）和表現。主要是因爲有FK約束，並且需要加入一張表才能獲得相關日誌（是的，這是一個RMDBS-MSSQL）。另外，由於每個日誌都有兩個表，所以還需要兩個插入（完整性查找等）。當然，這是正確的。但我看不到問題。特別是因爲性能最低，所以性能不佳。另外，要存儲的日誌在第一年最有可能不會超過5-10K。幾年之後，表格可能包含大約30-40K行，

您對上述有什麼看法？另外，您更喜歡上述哪一種解決方案，爲什麼？

來源

2011-02-18 RoboCop

「ExampleTaskAuditLog」 `和`AnotherExampleTaskAuditLog`表來存儲一個多對多的關係？ – Justin 2011-02-18 14:51:37

我不確定我完全理解 - 如果ExampleTaskId和AnotherExampleTaskId是相同的數據類型，爲什麼不只有一個表具有以下列？

編號
說明
創建
任務id
任務類型

這且不說，你AuditLog表絕對應該有一個TaskType場，否則就變得相對困難弄清楚記錄在哪種類型的記錄中日誌代表。除非絕對必要（例如性能方面的原因），否則我會避免（在可能的情況下）對您的表進行非規格化（即，對於給定的任務類型，列將始終爲空）。相反，我推薦使用表和聯接的任務具體列：

Table ExampleTaskAuditLog 
------------------------------ 
AuditId (PK) 
TaskSpecificField 
AnotherTaskSpecificField

來源

2011-02-18 14:47:18 Justin

我同意。我會有一個審計表，其中包含所有任務的記錄。爲每個任務設置不同的表格可能會變得很亂。你可能認爲你只有一對夫婦，但突然之間，審計員就會停下來告訴你還有15件事需要審計。另外，如果你說的行數不多，就不會有性能問題。 – 2014-04-08 17:25:00

假設你正在登錄事件/任務/行動，而不是修改單個表，我會與第一次去，對同一@Kragen說的原因（upvoted）。但是，如果您正在審覈對單個表的更改，那麼我將爲每個正在審計的表使用一個審計表。

一個問題，你真的想要那些外鍵嗎？如果表中的項目（行）被刪除，那麼您將不得不刪除該項目的審計線索。你只需要現有項目的審計日誌？（「審計」一般意味着「觀察他們的行爲」，如果「他們」能夠消除他們通常不贊成的活動的痕跡，即使在華爾街也是如此）。

來源

2011-02-18 15:06:31

SQL - 審計日誌表設計 - 您更喜歡哪一個？

回答

相關問題