類似結構的理想數據庫模式

在我們的業務應用程序中，我們需要存儲用戶或系統生成的關於特定實體的「評論」。例如，可以創建關於客戶，訂單或採購訂單的評論。這些評論都具有許多相同的特徵，但被引用實體除外。類似結構的理想數據庫模式

所有評論需要日期，時間，用戶和評論文字。他們還需要引用表的外鍵，以便您可以查找該特定實體的註釋。

當前應用程序爲每種評論類型（例如，customer_comments，order_comments，purchaseOrder_comments）都有一個單獨的表格。這些表格的模式在日期，時間，用戶和評論文本方面都是相同的，但每個表格都有一個FK給評論所針對的相應表格。

這是最好的設計還是有更好的設計？

就個人而言，我會創建一個單獨的評論表，然後爲每個實體（客戶，訂單等）使用一個交集表來將評論與實體關聯起來。

enter image description here

2011-09-23 21:00:07

我和你在那裏。這是目前提出的答案中唯一允許您放置/強制FK約束的答案。我曾與一個等效體系結構（引用多個外部表）以及至少一個進程獲取屬於錯誤關係的行。 –

是的，我認爲執行FK關係非常重要，而且這種模式清楚地表明瞭這一點。謝謝！ –

如果它一直我，我想我會有一個Comments表額外comment_type_id字段映射到評論是否應該可用於customer實體，order實體，等等......別的地方你會需要有comment_type_id所指的comment_type表。

這樣一來，如果你決定要一個額外的一塊元數據添加註釋，你只需要做到在一個單一的Comments表，而不是在customer_comments，order_comments等..

我對這個結構的擔憂是它不允許執行FK關係。你有一個模棱兩可的FK領域。我想我應該澄清說FK執法應該是一項要求。 –

，你可以把所有這些評論到一個表comments並添加另一列commented_table，這將使其成爲一個多態多對一。一些框架/ orms（如Rails的ActiveRecord）確實支持這一點，如果你正在使用的東西沒有，它基本上就像添加另一個where子句一樣簡單

2011-09-23 21:00:23

回答