我正在開發一個Web應用程序，其中我將有客戶和供應商。客戶和供應商數據庫設計問題
最初我想過使用Customers表和Suppliers表。
然後，當我在考慮銀行交易時，我注意到每筆交易都需要引用客戶或供應商，所以我想使用一張名爲Business的表，我將爲其節省客戶和供應商。
如果我使用客戶和供應商表，當我想列出銀行交易時，我將不得不在兩個表中搜索以獲取公司名稱。
如果我使用Businesses表，則必須使用業務類型列，併爲所有業務類型組合可能的字段。
關於設計的任何建議？
您需要問的問題是客戶和供應商之間常見的信息。如果信息（和使用該信息的）基本相同，則將它們存儲在同一個表中可能是確定的。如果信息（或使用信息）在很大程度上不同，那麼您應該單獨存儲它們，並在包含銀行交易所需的信息之間創建一個共同視圖。
你的兩個想法對你的問題都是有效和正確的解決方案。要知道正確的答案，您需要考慮應用程序的預期使用模式，以決定哪個更適合。例如，您是否會比分別列出客戶和供應商更頻繁地列出所有銀行交易？
問題是，您的客戶是否也可以成爲供應商？在許多企業中，顧客是從你那裏購買的實體，而替代者是賣給你的業務，同一個實體可以在不同的時間完成這兩件事情。在金融行業，這些被稱爲「交易對手」，我從來沒有見過將他們區分爲單獨表格的金融交易系統。
答案在於兩個方面：a）兩種類型的對象（客戶和供應商）只是同一枚硬幣的兩面，或者它們根本不同，b）是否會產生更易於維護，明智的數據庫模式？
您必須從業務邏輯角度和核心RDBMS角度考慮影響。能否將交易表中的外鍵定義到客戶表和供應商表中有價值嗎？
您真的會在您的應用程序中進行搜索，其中客戶結果和供應商結果混雜在一起嗎？如果是這樣，我會建議創建一個視圖，將公共部分聯合起來，並將表格分開。請記住，其他信息（如地址或電話號碼）可以存儲在其他謹慎的表格中，因此很多常用信息將被重構。
我不想重複其他人所說的話，但是想要在您的客戶和供應商的具體使用案例中補充一點，要注意取決於您的域名是客戶可能成爲供應商。
讓我們假裝我們正在銷售汽車零部件。經銷商是客戶，因爲他們從其他經銷商購買零件（例如零件缺貨時）。所以經銷商既可以是客戶，也可以是供應商。
我通常通過定義業務或公司實體來模擬客戶供應商關係，這定義了我們正在處理的人員。姓名，地址等等。然後我會定義一個顧客，顧客是一個企業，一個顧客是一個企業的顧客，所以你將擁有顧客是誰，顧客是誰。然後，您可以使用關於關係的其他信息來修飾您的客戶。
您可以對供應商進行相同的操作。你也可以把這個抽象出來，並有一個關係表，但它會變得複雜，並且你失去了一些意義而沒有太多收穫。
我認爲你最好的答案來自用戶域。是否有任何客戶和供應商信息由相同用戶（在相同角色中）共同維護？如果是這樣，如果他們可以爲了兩個目的在一個地方改變信息，他們會更容易。如果沒有，你會讓他們改變彼此的數據，這不會讓任何人開心。
如果您有獨立的採購和銷售系統並需要與他們接口，則會出現同樣的問題;或有一個企業系統（在這種情況下，你應該可以匹配它的作用）。
問題 - 你是從用例或用戶故事中得到你的需求還是......？
客戶和供應商。錯誤。它是供應商和買家 - 標準商業關係的兩個方面。術語「客戶」是一個僅用於營銷部門的概念 - 它的含義是基於上下文的，因此對於任何特定的業務流程來說都是抽象的。只有將客戶定義爲一種類型的關係（如「買方」）纔會起作用 - 這似乎毫無意義和困惑。
兩個陣營中可能存在一個組織/人員的想法完全是巧合。如果企業要求你知道某個給定方在兩種業務關係中都存在，那麼他們必須能夠以某種方式控制這些信息 - 而且控制方法必須由業務決定 - 你無法發明它。必須有一條業務規則，使企業能夠了解並記錄同一方參與兩個不同的方面。
如果業務規則不支持，則無法創建適用的數據結構。這真的很簡單。