如何利用多个数据库挽救参照完整性

时间:2008-10-21 22:39:21

标签: database-design integrity

我正在设计一个系统,用于为全国各地的几个生产站点提供信息(所有信息都在一个站点中),可能会增加更多。最初我认为只能使用一个数据库就可以逃脱。我现在正在重新思考我的原始设计,并倾向于采用更具可扩展性的解决方案。保持每个数据库/表的大小也很重要。

将有一个“主”数据库,其中包含跨站点概念的信息,然后是每个站点的单独数据库,其中包含特定于站点的信息。

我的斗争是将数据分开的地方。数据都非常相关。无论我在哪里,我都会失去一些参照完整性。我读过的所有内容都是为了不惜一切代价避免这种情况,因为我认为这是非常好的理由,但我没有看到解决方法。

我已经研究了触发器,但是如果数据库位于不同的服务器上,我认为它们不起作用(虽然不确定 - 我认为Oracle会这样做)。我只限于一个开源解决方案,所以如果它有帮助的话,它将是MySQL或postgre。

有没有人提出一些缓解此问题的建议或有其他设计建议?

5 个答案:

答案 0 :(得分:1)

在不了解您的具体情况的情况下,提供帮助有点困难 - 但这是我的直觉......

我猜你所建议的信息应该放在你的'Master'数据库中,或许比每个站点的数据库更稳定(对数据的更改次数很少)。

也许您可以查看一个解决方案,其中“主”数据库中的数据也存储在每个站点的数据库中。然后,您可以查看某种复制系统,以将对主数据库所做的更改传播到站点数据库。

这样,您仍然可以在每个站点的数据库中维护引用完整性。

答案 1 :(得分:0)

MySQL有federated tables,但不清楚外键约束是否适用于它们。我有点怀疑 - 但应该触发。

否则,您必须将您的参照完整性向上移动到应用程序中。

答案 2 :(得分:0)

你在谈论多少数据?你真的需要这种架构吗?数据库可以带来很多容量。

“不要这样做”的警告来自艰苦,痛苦的经历。分布式数据集只是维护和管理的真正难题。所以,要认真考虑做到这一点。

或许考虑将数据分解为运营商店与报告商店或数据仓库,您可以每晚或每周提供数据(取决于您需要分析报告的最新流量)。许多运营数据存储不需要那么大。

对于仅在后端维护的表(例如,出于数据完整性目的)与用户经常更新和添加的操作表,这也是一个不同的问题。可以考虑更多“静态”表 - 简单地说是静态的。如果有必要,可以使用可靠的程序在节点之间更新它们,理想情况下很少。

一旦您的数据进入“动态”与“静态”表,分区就会容易一些,因为您的静态数据可以根据需要单独掌握和复制(从根实例),而分区存储是单一的用于为后端数据仓库和报告系统提供信息的真相来源。然后,几乎没有必要的实际复制,而是更多的是“哪个机器在它上面”的问题,可以很容易地自动化。

答案 3 :(得分:0)

如果理解正确,您希望(可能)使用触发器检查每个插入/更新/删除是否在远程数据库上保留参照完整性?

如果是这样,我认为你应该避免这种情况,我只是看到性能开销太大的问题。特别是如果您希望解决方案可扩展。

我会担心数据是如何插入的,并且对它非常严格,你的应用程序逻辑应该涵盖这一点,这是一个很高的细节。您可以运行每周报告以查看哪些数据不正确并查看错误插入的原因等,但我认为如果您的应用程序正确完成,则很难实施多数据库参照完整性。

但是不要误解我的意思,我100%保持数据处于稳定,稳健的状态,但有时这并不总是可以强制执行。

但正如前面所述,没有关于解决方案的更多信息,很难给出建议...... :)

答案 4 :(得分:0)

让我看看我是否可以为问题域提供更好的概要:

希望创建一个“企业”解决方案,其中n个生产地点将增加n。

我们处理数据以创建Web和打印文档。

系统将管理流程以将数据文件从提交(通过集中式网站)传输到打印机或网络或两者。

每个生产站点都有自己的客户等。所有这些信息都将存储在数据库中。该信息的大多数管理将发生在中央站点

由于我们使用的软件中的许可限制,我们在一台服务器上处理数据。

因此会有一个守护进程查看队列(在数据库中)并处理作业。流程将由数据库中的状态列控制,以便其他进程知道它在过程中的位置。

大量数据出现在我们的网络工具中。我们需要为我们为Web生成的每个文档存储搜索索引。这变得相当快。这些记录不会永久保留,但至少大部分时间都会很大(估计有5亿行)。

我认为要摆脱表大小问题,单独的db可能是答案以及在不同服务器上分离生产站点的能力。

事情是我不知道什么时候会获得另一个网站或者它会有多大。

我想我想把可扩展性的事情扼杀在萌芽状态,而不是一年之后获得一个推动我们超越边缘的网站而不必购买更好的服务器来容纳怪物。不幸的是,金钱是一个对象。

如果增长不是未知数,我甚至不会考虑数据库。

我还考虑过为每个站点完全创建单独的数据库。这使得我们的应用程序管理变得更加困难以及其他问题。

我为分散的反应道歉。这是一个12小时的一天。我真的可以永远继续下去,但希望无论如何都能提供更多的见解。

与一个数据库的示例关系

网站有很多客户 客户有很多提交者 提交者有很多提交 提交有很多文件 文件有很多索引

因此,我可以通过连接轻松计算客户的文档数量