存儲Web應用程序的文件和註釋。表設計

Question

我有一個Web應用程序與幾個實體（表）。每個人都有他的CRUD頁面。

我想添加一些，添加註釋和附加文件的能力。

我在想兩種情況。

1. 所有註釋/文件的一個表 - 表中將有一些實體和特定記錄的ID。
2. 對於每個實體一個單獨的評論/文件表。

這些文件將存儲在磁盤上的一個目錄中。表中將文件的名稱和一些額外的信息。

Answer 1

這是一個折衷。使用單一評論表，您會得到一個簡單的DRY（不要重複自己）模式，但不會獲得外鍵約束，因此不會級聯刪除。因此，如果您刪除帶有評論的實體，則還必須記得刪除評論！

如果你使用多個註釋表，你會得到FK約束和級聯刪除，但你有一個「溼」模式（你在重複自己）。例如，每個評論表可能有一個commentbody列。如果更改該列定義，則必須在每個評論表中更改它！

DRY-er模式的一個有趣的解決方案可能涉及表繼承（請參閱http://www.postgresql.org/docs/9.0/interactive/ddl-inherit.html），但請閱讀第5.8.1節。注意事項，因爲在索引方面有一些「陷阱」，至少在postgres中。

無論哪種方式，對您的認可思考您的數據庫設計的榮譽！

Answer 2

在應用程序方面有一個唯一的所有評論表的設計似乎是有道理的。就應用程序代碼而言，這意味着相同的SQL將被重用於所有實體。這是大多數應用程序使用的「經典方式」，它擴展爲具有用於處理所有對象的註釋和附件的相同的活動記錄和控制器。

就SQL而言，第二種解決方案可能對於像MySQL這樣的一些數據庫有用內存緩存的好處。第一個解決方案中添加的每個評論/附件都會從內存緩存中刪除影響評論表的所有請求。對於單個表格，對一個實體的評論不會使對其他實體的查詢無效。但是你會需要更多的文件描述符和更大的表緩存....所以要選擇這個解決方案，你需要一個基於真實，精確，案例的決策，在那裏你可以比較數據庫訪問速度的好處。而當你添加新的實體時，你一定會發現你的每個實體都有一個評論表解決方案無聊，通過使用1st解決方案，事情可能會自動化。