复杂的数据库设计

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数据库的性能。