處理這些MySQL數據庫關係的最佳方法是什麼？

Question

我正在建立一個小網站，讓用戶將他們最喜歡的書籍推薦給海誓山盟。所以我有兩張桌子，書和小組。用戶可以在他們的圖書館中擁有0本或更多書籍，並且一本書屬於1個或更多組。目前，我的表是這樣的：

books table 
|---------|------------|---------------| 
| book_id | book_title | book_owner_id | 
|---------|------------|---------------| 
| 22  | something | 12   | 
|---------|------------|---------------| 
| 23  | something2 | 12   | 
|---------|------------|---------------| 

groups table 
|----------|------------|---------------|---------| 
| group_id | group_name | book_owner_id | book_id | 
|----------|------------|---------------|---------| 
| 231  | random  | 12   | 22  | 
|----------|------------|---------------|---------| 
| 231  | random  | 12   | 23  | 
|----------|------------|---------------|---------| 

正如你所看到的，用戶+書籍和書籍+羣體之間的relationsships表中定義。我應該在他們自己的表中定義關係嗎？事情是這樣的：

books table 
|---------|------------| 
| book_id | book_title | 
|---------|------------| 
| 22  | something | 
|---------|------------| 
| 23  | something2 | 
|---------|------------| 

books_users_relationsship table 
|---------|------------|---------| 
| rel_id | user_id | book_id | 
|---------|------------|---------| 
| 1  | 12   | 22 | 
|---------|------------|---------| 
| 2  | 12   | 23 | 
|---------|------------|---------| 

groups table 
|----------|------------| 
| group_id | group_name | 
|----------|------------| 
| 231  | random  | 
|----------|------------| 

groups_books_relationsship table 
|----------|---------| 
| group_id | book_id | 
|----------|---------| 
| 231  | 22  | 
|----------|---------| 
| 231  | 23  | 
|----------|---------| 

感謝您的時間。

Answer 1

帶有四個表的第二種形式是正確的。您可以從books_users_relationsship中刪除rel_id，因爲主鍵可能與user_id和book_id合成，就像在groups_books_relationsship表中一樣。

Answer 2

您不需要「關係表」來支持關係。在數據庫中，在子表中實現外鍵定義了父和子之間的關係。只有當表包含數據或解決多對多關係（並且沒有除父項主鍵之外的數據）時，才需要表。

您面臨的第二個問題，關係變得複雜甚至可選的原因是由於前兩個表未被歸一化。由此產生許多問題。

• ，如果你在book仔細一看，你可能會注意到，同樣的book（標題）被重複

• 同樣，有（一）一書沒有區別在它存在的條件世界及（b）一書，由成員所有的副本，可供借用

  • 如。該評論是關於現有的book一次，並且適用於book的所有副本;而不是擁有的book。
    。

• 你的「關係」表中也有數據，數據重複。

• 所有這些重複的數據需要保持並保持同步。

• 如果數據是標準化的，所有這些問題都會被消除。

因此（因爲你正在尋找的「最佳辦法」），該序列是第一數據標準化，之後（毫無疑問）的關係很容易，不復雜，不會有重複數據（以表或關係）。

• 正火的時候，最好是現實世界（不是整個現實世界，但無論你是在數據庫中執行它的一部分）進行建模。這將數據庫與變更的影響隔離開來，並且將來的功能擴展不需要更改現有的表。

• 同樣重要的是使用正確的名字表和列，出於同樣的原因。 group在非特定的情況下，將在您實施其他某種形式的分組時出現問題。

• 的關係能夠在正確的「水平」被定義現在，正確的表之間。

• 需要在移動的所有內容上粘貼Id列嚴重阻礙了您理解數據和歸一化過程以及搶奪關係能力數據庫的能力。

  • 請注意，現有密鑰已經是唯一且有意義的，簡短且高效，不需要額外的代理鍵（及其附加索引）。作爲外鍵，MemberIds`顯示它們在其中使用的明確角色。

• 注意，當你認爲你的問題的空間不是那麼簡單，它是作爲一個案例研究，並與運教程爲SQL（如MS SQL中，Sybase）。

▶Social Library Data Model◀

讀者誰是不熟悉標準建模關係型數據庫可能會發現▶IDEF1X Notational◀有用。

我已經提供了支持借閱所需的結構，以再次說明在歸一化數據上實現關係是多麼容易，並且顯示借用所依賴的正確表格（它不在任何書籍和任何人之間;僅在國有書籍可以借用）。

• 這些問題非常重要，因爲它們定義了數據庫的參照完整性。

• 同樣重要的是落實在數據庫本身，這是標準的位置（而不是在應用程序代碼，所有的地方）。聲明式參照完整性是IEC/ISO/ANSI標準SQL的一部分。這個問題有一個數據庫設計標籤。

• 無法在非SQL中定義或強制實施引用完整性（有時可以定義引用完整性但它沒有被強制執行，這會造成混淆和欺詐）。儘管如此，您可以設計和實現特定非SQL支持的數據庫的任何部分。

如果您有任何不明白的地方，請隨時提問，作爲評論或作爲您的問題的編輯。