具有多站点的系统的数据库结构 - 数据库＆amp; PHP

Question

我正在使用的系统结构如下。鉴于我计划使用Joomla作为基础。

a（www.a.com），b（www.b.com），c（www.c.com）是搜索门户网站，允许用户搜索预订。

x（www.x.com），y（www.y.com），z（www.z.com）是指由用户预订的酒店。

• www.a.com的用户只能搜索其中的预订 www.x.com
• www.b.com的用户只能搜索其中的预订 www.x.com，www.y.com
• www.c.com的用户可以搜索所有预订 www.x.com，www.y.com，www.z.com

所有a，b，c，x，y，z运行相同的系统。但他们应该有不同的域名。因此，根据我的发现和研究架构，应该如上所述API集成所有数据库调用。

鉴于此处仅显示了6个实例（a，b，c，x，y，z）。最多可以有100种不同的搜索组合。

我的问题，

我应该为整个系统维护一个数据库吗？如果是这样，如果需要，我如何拔出一个实例（例如：从系统中删除www.a.com或从系统中删除www.z.com）？由于我使用的是mysql，由于记录的数量，系统不会很麻烦吗？

如果我为每个实例维护单独的数据库，我该如何进行搜索？如何将所需记录集成到一个并进行搜索？

是否有不同的数据库方法可供使用而不是上面提到的？

Answer 1

你描述的问题是“多租户” - 这是一个相当棘手的问题需要解决，但幸运的是，其他人写了一些useful approaches。 （虽然该链接指向Microsoft，但它适用于除细节之外的大多数SQL环境）。

您案例中的权衡取舍是：

• 您酒店的数据是否适合单一架构？他们的“空缺”记录是否具有相同的字段？
• 会有多少家酒店？ 3个独立的数据库有点可管理; 30可能不是; 300绝对不是。
• 数据库有多大？有多少空缺记录？
• 数据结构随时间变化的可能性有多大？一家酒店有多大可能需要改变其他酒店？

到目前为止，最简单的管理和开发是“单一数据库”模型，但前提是数据在模式中是中等同质的，并且只要您能够以合理的性能查询数据。我不担心在MySQL中放入大量记录 -​​ 它可以很好地扩展。

在这样的设计中，您可以在查找表中将“portal”映射到“hotel”：

PortalHotelAccess

PortalID   HotelID
-----------------
A          X
B          X
B          Y
C          X
C          Y
C          Z

Answer 2

我可以建议2种方法。选择哪一个取决于有关整个系统的一些额外信息。事实上，主要的问题是你的系统是否可以从消费者的角度（a，b，c等）模拟任何数据提供者（x，y，z等）（从法律意义上说是替代）

集中式数据库

第一个实际上是基于您使用集中式API的原始方案。它意味着一个单一的搜索引擎，从数据源收集所需的数据，将其聚合在自己的数据库中，并提供给数据消费者。

如果数据源的数据表示不同，这很可能是一种优选的解决方案，因此您需要对其进行预处理以保持一致性。此变体还可以保护您的客户免受连接中可能出现的问题的影响，即如果其中一个源站点在短时间内脱机（我认为这可能甚至长达几个小时而对预订服务的实际情况没有太大影响），您仍然可以处理对脱机站点的请求，并将所有新文档存储在中央DB中，直到问题解决。另一方面，这意味着您应该在数据库和每个数据源站点之间提供某种双向同步。此外，集中式数据库应该首先考虑可靠性而创建，因此它似乎应该分布（最好是分布在不同的数据中心）。

因此 - 这种方法可能会提供最佳的用户体验，但需要付出足够的努力才能实现强大的实施。

多个本地数据库

如果每个数据提供者都运行自己的数据库，但所有数据提供者（包括后端API）都基于单一标准，则无需将数据复制到中央数据库。当然，中心点应该保留，但它将仅在没有DB的情况下托管中间层逻辑。该层实际上是一个API，它将（x，y，z）与适当的（a，b，c）绑定 - 这是一种配置，仅此而已。每个消费者站点都将托管从中心点加载的小部件（可以只是一个javascript或完全成熟的Web应用程序），并在其中嵌入适当的设置。

小部件将直接请求所有指定的后端，并将其结果汇总到一个列表中。

这个变体很像今天的大多数Web应用程序工作，它实现起来更简单，但它更容易出错。