複雜的數據庫設計

Question

我們公司有一個數據庫設計的情況。我們試圖找出設計數據庫來存儲事務數據的最佳方式。我需要專家對最佳關係設計的建議來實現它。問題：例如，我們的系統中有不同類型的「實體」客戶，服務，經銷商等。這些實體之間正在進行資金轉移。我們需要在數據庫中存儲傳輸的歷史記錄。

解決方案：轉移

1. 一個表和另一個表，以保持「帳戶」的信息。有三個表格「客戶」，「服務」，「經銷商」。還有另一個表「帳戶」。帳戶可以與上述任何「實體」相關聯;這意味着（這就是要求），從邏輯上說，實體和賬戶之間應該存在一對一的關係。但是，我們只能將Account_ID存儲在Entities表中，但我們無法將實體的外鍵存儲在Accounts表中。這裏的問題發生在數據庫設計方面。因爲如果有客戶的帳戶，它不受數據庫設計的限制，不會被存儲在服務表等中。現在我們只能將所有傳輸保留在一個表中，因爲帳戶在所有實體之間是統一的。
2. 將餘額信息保留在表主實體表中，併爲所有傳輸保留單獨的表。這裏對於實體之間的所有類型的轉移，我們保留單獨的表格。例如，客戶和服務提供商之間的轉賬將存儲在名爲「支出」的表格中。另一個表格將具有用於在服務和經銷商之間傳輸的傳輸數據，稱爲「佣金」等。在這種情況下，我們並沒有將所有資金轉移存儲在單個表格中，但是由於表格「支出」和「委員會」僅在兩個具體實體之間。

根據最佳實踐，上面給出的哪一種解決方案是正確的，爲什麼？

Answer 1

如果您只是在尋找聲稱處理類似案例的模式，則會有一個包含數百個已發佈模式的網站。其中一些涉及存儲有關客戶和供應商的交易數據。你可以採取其中之一併適應它。

http://www.databaseanswers.org/data_models/

如果您的問題是關於如何帳戶涉及到的業務聯繫，請繼續閱讀。

客戶，服務和經銷商都是我將稱之爲「聯繫人」的一些超類的子類。有兩種衆所周知的設計模式用於建模數據庫表中的子類。還有一種稱爲共享主鍵的技術，可以與其中一種技術一起使用以獲得更好的優勢。

看看info和這三個標籤下分組的問題：

single-table-inheritanceclass-table-inheritanceshared-primary-key

如果使用類表繼承和共享主鍵，將結束與四個表有關聯繫人：聯繫人，客戶，經銷商和服務。聯繫人中的每個條目都會在三個子類表之一中有相應的條目。

賬戶表中的FK，我們稱之爲Accounts.ContactID將不僅引用聯繫人中的一行，而且還引用客戶，經銷商，服務中與所處案例相關的行。

這可能適合你。或者，在一些簡單的情況下，單表格繼承可以很好地工作。這取決於您的數據的細節和您的預期用途。

Answer 2

您可以使用FK將三個字段的客戶，經銷商和服務的帳戶帳戶，它會關閉問題。但是你也可以爲每種具有會計數據的實體制作三張表。您在系統設計中處理了多系統案例。每個系統解決任務。但是爲了確定你需要對算法的複雜性，性能和其他系統需求進行優劣分析。例如，一個表將更簡單的編碼，但三個表提供更多的SQL數據庫的性能。