规范化到不同的数据库？

Question

对于跨多个数据库规范化数据库，每个人的意见是什么？例如，假设您有一个允许不同客户销售产品的数据库。您已经抽象了订单，订单商品等的概念，但每个客户都希望在此处或那里添加不同的字段。

您可以将字段添加到特定表中，创建一个宽表，其中包含的值并非所有客户端都使用，或者您可以创建一个列出列名和值的高表，以使其显示为您要将列附加到特定对象（例如，当仅存在工作电话号码时，需要订单表上的家庭电话号码。）

或者您可以规范化到具有名为CustomOrder的表的客户端特定数据库，该表保留通用数据库中的原始订单ID，然后添加容纳客户端所需的列。

有人使用过像这样的解决方案吗？我知道参照完整性很难在数据库中控制，但它确实使原始通用数据库保持小而精简，同时允许客户根据自己的内容进行自定义。

每个人对这种设计的想法是什么？

Answer 1

我在那个环境中工作过，这成了一场真正的噩梦。我们有一个主应用程序，由一个团队管理，其他人管理客户端特定的自定义。然后问题变成了多个客户端获得了类似但不完全相同的定制（尽管如果有人在设计自己的客户之前看到其他客户正在做什么的话，他们本来可以）。由于执行适用于每个人的主要应用程序的团队是由公司而不是个人客户支付的，我们从来没有足够的人来概括特定的客户需求，以便其他人可以在需要时使用它们并因此创建20个不同的定制解决方案做同样的事情。此外，由于客户截止日期往往比一般团队可以处理的更快（100个开发人员中只有两个），即使某些事情能够很好地进行，也会在客户端数据库中处理以满足交易要求。很快就出现了如此大的混乱，重构数据库以修复设计缺陷变得不可能，因为有太多不同的可能应用程序可能受到影响，没有人敢尝试重构。那么会发生什么事情就是针对特定问题实施了修复，但旧方法将保留在那里，每个客户端都会选择不同的方式来实现主应用程序数据库中的东西。尝试在设计团队创建之后添加设计团队的组织变更然后导致几乎完全停止可以完成的工作，因为没有完全重写现有站点（没有完全重写现有站点），新工作都没有达到新的设计标准当然客户不想支付，因为当前版本对他们工作得很好）。离这个模特很远！

Answer 2

我绝对会建议远离创建多个数据库，这听起来像你想要的是这样的Entity Attribute Value model。如果您需要扩展创建多个数据库的方法，那将会更加困难。

Answer 3

我曾经使用过Siebel CRM系统，该系统允许对其固定应用程序进行大量定制。它通过允许扩展表来做到这一点。例如，Customer的扩展表与Customer表具有一对一的关系，并且其中包含所有添加的列。

Answer 4

拥有这样的东西是一个好主意。理论上它很有效。但即使对特定应用领域进行特殊处理，您也会遇到麻烦。每个应用程序可能具有不同的业务逻辑（验证算法）。现在，在一个应用程序中有效的记录可能在另一个应用程序中无效。我的建议就是这个。

保持数据库分开但引入将它们链接在一起的东西。例如，出于报告目的，您可能想要知道来自一个应用程序的客户A与来自另一个应用程序的客户B相同。创建一个表（数据库）链接各种数据库中的记录。

除非我知道你特定问题的具体细节，否则我不会更进一步。

PS：你所说的是Master Data Management。有些商业产品试图解决这个问题，但他们都没有说服我真的有效（是的，这是为了查询数据，但更新怎么样？）。

Answer 5

我不确定您如何将“标准化”一词与您的建议联系起来。但我认为这是一个严格的反模式，在我熟悉的任何SQL理论或实践文献中都没有被推荐。