我有一個表格列表，例如學生，老師，工作人員，部門。等等，每個表格都有特定的評論。現在表格中的一條記錄可以有一條或多條評論，表明這是從任何表格到評論表格的一對多關係。我不知道最好的方法是將評論表與每個評論表聯繫起來。如果我將註釋表中的外鍵放到這些表中的每一個表中，它將像40-50個字段一樣取決於否。的表格。其次，如果我將這些表中的每個表中的外鍵添加到備註表中，就像重複第二個備註外鍵的整行一樣？同樣，如果我在每個表中僅使用一個字段作爲註釋，我實際上只將行存儲在一個文本字段中。有關如何實現高效解決方案的任何建議？我如何將一張桌子與許多不同的桌子聯繫起來？
讓我們假設你的表（學生，教師，職員，部門）都有一個名爲Id的int主鍵。
對於你的評論表，你可以創建一個表。
Id int
CommentType enum (student, teacher, staff, dept)
LinkId int
Comment
在評論一個行可能看起來像這樣
1,'Student',347,'text'
是學生或老師或工作人員不只是一個類型的人..
讓你有一個人，一個人可以有很多意見？所以你有一個關於此人的personscomments表，爲什麼有話table..is此言不只是一個類型的註釋..
其很難看到沒有更深入的架構
你可以使用中間的「多對多」表。每個基表（學生，教授等）都會有一個改變的自我存儲一個外鍵給基表（例如student_id）和一個外鍵給調度表。實際上，您的表格數量增加了一倍，但不需要修改現有的表格，並且可以獲得充分的靈活性。
如果你想保留外鍵約束，你需要一個表來處理每個將有子註釋的表的映射。
含義，註釋將有一個主鍵，對處理該映射的每個表有一個外鍵約束。
然後，在映射表中，您將具有外鍵約束的comment_id和__id用於approriate表。
您的意見表可以如下所示：
CommentID (int) - Primary Key TableName (varchar(250)) - Table the comment is related to RecordID (int) - the ID of the record in the table referred to Comment (text) - the actual comment
你當然可以添加可選的領域，如時間戳，這將讓你選擇他們輸入的順序意見。
現在，您可以使用此表存儲任何表的註釋，並且您可以通過篩選表名和記錄ID來選擇它們。
由於這是一個多對多的關係，你migth可能想看看使用關聯表。
使用您的例子，它可能是這個樣子：
你的表，可以有評論：
+----------+------------+
| student | student_id |
+----------+------------+
| Steve | 12 |
| Larry | 57 |
| Sunshine | 88 |
+----------+------------+
+--------+---------+
| dept | dept_id |
+--------+---------+
| Math | 2 |
| P.E. | 5 |
| Drama | 12 |
+--------+---------+
然後，你需要跟蹤的實際意見：
+-----------------------+------------+
| comment | comment_id |
+-----------------------+------------+
| I love Math! | 3 |
| Larry is my hero... | 5 |
| Sunshine <3 Me! | 6 |
+-----------------------+------------+
現在，您需要這些表格之間的關聯，這是您的關聯表格發揮作用的地方。你現在聯繫什麼學生或部門有什麼意見，像這樣：
+------------+------------+
| student_id | comment_id |
+------------+------------+
| 57 | 5 |
| 57 | 6 |
+------------+------------+
+---------+------------+
| dept_id | comment_id |
+---------+------------+
| 2 | 3 |
+---------+------------+
這是既有效又優雅。試一試！
（併爲您節省也許是另一個問題）
你當然可以使用，如果您擔心有這麼多的關聯表只是一個關聯表的，但我會建議反對它，因爲它並不像整潔，消除了參照完整性檢查一些可能性，你可以與第一個解決方案：
+-----------+------------+---------+
| entity_id | comment_id | entity |
+-----------+------------+---------+
| 57 | 5 | student |
| 57 | 6 | student |
| 2 | 3 | dept |
+-----------+------------+---------+
（而這又應該提示你添加一個查找表爲這些實體...但我們不要去那裏）
我的50美分：Zoredache解決方案絕對是好的，但我不鼓勵使用枚舉;它們在mysql中不是很聰明：如果你指定一個未知的值，那麼錯誤就用一個空字符串表示 - 即使指定了一些默認值。另外，如果你想修改或添加一個新類型，那麼對於ALTER來說很長。無符號的tinyint應該足以滿足您的大多數需求...
+1爲問題的經典解決方案。實際上，我已經看到Oracle設計的數據庫使用類似的結構來處理數據庫中的所有*解碼錶。在查詢時可能會有些雜亂，但肯定會簡化結構 – Cruachan 2008-11-18 10:19:22
感謝您提供最高效的解決方案。我有這種想法使用varchar表名稱，但我認爲Enum是最好的。 – hash 2008-11-19 10:53:56