考慮下面的數據庫的例子：外鍵或空值鏈接兩個長期遠離的表
articlessupplier和article之間的關係是多對多（（1，n） - （1，n））
假設我有clinic's id和I想要檢索它的所有suppliers，最好的方法是什麼？是通過爲每個供應商創建一個"null" article在article_supplier或創建一個foreign key在supplier引用適當的？
後一種解決方案可能看起來最簡單也最容易，但是當存在大型錶鏈時會發生什麼？每次我需要一個列表時，我是否會一直添加一個外鍵？例如：
如果它的確與衆不同，我使用Laravel雄辯的ORM
表格表示值之間的關係。 （有些值標識實體。）直到我們被告知每個表的基數或查詢結果是什麼，才能使用數據庫。表示：它的行滿足哪些業務/應用程序關係。 （即，它的（特徵）謂詞是什麼。）表格的關係是什麼？
要查詢我們用基礎關係表達關係，然後用相應的基表表達它的表。例如，一個連接返回滿足一個關係和另一個關係的行。我們再次需要了解表格在商業/應用方面的關係。
基數&約束條件是屬性給定的情況下可能出現的關係。他們不需要更新或查詢。他們可以指導設計&用於完整性。
什麼時候，在診所，你談論「其」供應商時，你不會說你的意思。 「有」，「它的」，「對」，「引用」，「適當的」 - 全部意味着沒有任何內容 - 它們是指相關實體，但他們不說它們在業務方面的關係/應用程序。這個設計包含沒有明確的關係在診所&文章。如果是這樣的話，你說什麼都沒有，我們可以把正確的行或看到行&瞭解情況。不過，你可以從供應商那裏得到臨牀供應商的行，「供」一個給定診所「有」的某篇文章。但是，你的意思是？例如，如果你想要對診所允許「有」供應商「的」一些文章，這是一個新的關係/表，不能從你有什麼派生。
創造article_supplier
這種關係/表中的「空」的每個供應商製品是article_supplier &剛纔描述的關係/表的特定組合。但只有這兩個更簡單。
建立在供應商的外鍵引用相應的診所
這將意味着，如果一個供應商「擁有」不止一個診所則有可能在新版本中的行，只有不同所有其他欄目; 正常化理論說這比最初的設計和clinic_supplier關係/表更差。這意味着，如果一個供應商「沒有」診所，那麼您需要一些類似於可空的FK（外鍵）的東西。
所以你可能想要一個clinic_supplier表。但是你應該發佈一個新的問題，在這個問題中你實際上說出了你正在談論的業務/應用程序關係。
你的問題&以下基本上是複製中的基本原則/概念來顯然適用於回答都是一樣的：
How do I find relations between tables that are long-distance related?
Required to join 2 tables with their FKs in a 3rd table
Best Solution - Ternary or Binary Relationship
您需要閱讀的信息建模數據庫設計教科書。
最後一句說明了一切。數據庫ddesign不僅僅是找出一些語法。 –
[它曾經是第一個！]（https://stackoverflow.com/revisions/46385211/1）我不明白你想說什麼關於「語法」;我不是在「表達」的意義上使用「謂語」，而是在「意義」的意義上。 （當然表達了某種表達方式。）我的答案都是關於語義的。 – philipxy
我的評論是針對OP，而不是針對您的迴應。我完全同意你的迴應。 –
在您的設計中： Supplier is a table。 文章是一張表。 由於供應商提供的文章，他們的關係是以鏈接它們的表格來表示的。所以，有一個supplier_article表。
診所是一張桌子。 你提到診所使用文章。 按照與上述相同的原則，診所與條款之間的關係應以表格的形式表達。這應該是clinic_article表。
雖然你沒有提到，但你必須看看出現的其他依賴關係。例如，一家診所執行程序和程序使用文章。
通過創建供應商的外鍵引用相應的 診所
這會假設，一個供應商可以永遠只提供一個診所。即使今天情況確實如此，明天也是如此，因爲您可能想要在同一地點規劃多個診所或使用同一個應用程序或數據庫。
診所和文章之間的界限應該是什麼意思？那麼其他人應該表達什麼呢？你使用什麼參考圖表進行繪圖？你用什麼參考*設計*？ PS圖是一個很好的額外，但[請始終包括所有文本作爲文本而不是圖像/鏈接]（https://meta.stackoverflow.com/questions/285551/why-not-upload-images-of-code-on-所以，當灰化-A-問題/ 285557＃285557）。 – philipxy