复杂的数据库设计

Question

我们公司的数据库设计有这种情况。我们试图找出设计数据库来存储事务数据的最佳方法。我需要专家的建议才能实现最好的关系设计。问题：例如，我们的系统中有不同类型的“实体”;客户，服务，经销商等。这些实体正在相互之间进行资金转移。我们需要将传输的历史存储在数据库中。

解决方案：

1. 一张转帐表和另一张表以保存“帐户”信息。有三个表“客户”，“服务”，“经销商”。还有另一个表“帐户”。帐户可以与上述任何“实体”相关;这意味着（并且这是要求）逻辑上应该与实体和帐户之间存在一对一的关系。但是，我们只能将Account_ID存储在Entities表中，但我们无法在Accounts表中存储Entities的外键。这里的问题出现在数据库设计方面。因为如果有客户的帐户，它不受数据库设计的限制而不存储在服务表等中。现在我们可以将所有转移保留在一个表中，因为帐户在所有实体之间统一。
2. 将余额信息保存在表主实体表中，并为所有传输保留单独的表。对于实体之间的所有类型的传输，我们保留单独的表。例如，客户和服务提供商之间的转移将存储在名为“支出”的表中。另一个表将有服务和经销商之间的转移数据，称为“委员会”等。在这种情况下，我们不会将所有资金转移存储在一个表中，但外键是正确定义的，因为表“支出” “佣金”只在两个特定实体之间。

根据最佳实践，上述哪一种解决方案是正确的，为什么？

Answer 1

如果您只是在寻找声称可以处理像您这样的案件的模式，那么就会有一个包含数百个已发布模式的网站。其中一些涉及存储有关客户和供应商的交易数据。你可以采取其中之一并进行调整。

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

如果您的问题是如何将帐户与业务联系人联系起来，请继续阅读。

客户，服务和经销商都是某些超类的子类，我称之为联系人。有两种众所周知的设计模式用于在数据库表中建模子类。并且有一种称为共享主键的技术可以与其中一种技术一起使用，以获得良好的优势。

查看这三个标签下分组的信息和问题：

single-table-inheritance class-table-inheritance shared-primary-key

如果您使用类表继承和共享主键，最终将有四个与联系人相关的表：联系人，客户，经销商和服务。 Contacts中的每个条目都将在三个子类表之一中具有相应的条目。

帐户表格中的FK，我们称之为Accounts.ContactID不仅会引用“联系人”中的行，还会引用客户，经销商，服务中与该案例相关的行。

这可能对你有用。或者，单表表继承在一些更简单的情况下运行良好。这取决于您的数据及其预期用途的详细信息。

Answer 2

您可以将具有FK的三个字段的表帐户创建给客户，经销商和服务，这将关闭问题。但是，您也可以为每种类型的实体制作三张表，并附上会计数据。您可以在系统设计中处理多系统案例。每个系统解决任务。但是对于deсision，您需要对算法复杂性，性能和其他系统要求进行优缺点分析。例如，一个表将更简单的代码，但三个表提供更多的性能的SQL数据库。