具有多站点的系统的数据库结构-数据库&；PHP

我工作的系统结构如下。考虑到我计划用乔姆拉作为基地

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，所以它不会因为记录的数量而对系统造成麻烦吗

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

---

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

我可以推荐两种方法。选择哪一个取决于关于整个系统的一些附加信息。事实上，主要的问题是，您的系统是否可以从消费者的角度（a、b、c等）模拟（在法律意义上，取代基本身）任何数据提供者（x、y、z等）

集中式数据库

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

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

因此，这种方法可能会提供最佳的用户体验，但需要足够的努力才能实现健壮的实现

多个本地数据库

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

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

---

此变体与当今大多数web应用程序非常相似，它的实现更简单，但更容易出错。

您描述的问题是“多租户”——这是一个相当棘手的问题，需要解决，但幸运的是，其他人已经编写了一些。（尽管该链接指向Microsoft，但它适用于大多数SQL环境，详细信息除外）

您的案例中的权衡是：

• 来自酒店的数据是否符合单一模式？他们的“空缺”记录是否有相同的字段
• 有多少家旅馆？3个独立的数据库是可以管理的；30可能不是；300绝对不是
• 数据库将增长多大？有多少空缺记录
• 数据结构随时间变化的可能性有多大？一家酒店需要改变而其他酒店不需要改变的可能性有多大

到目前为止，管理和开发最简单的模型是“单一数据库”模型，但前提是数据在模式中具有适度的同质性，并且您可以以合理的性能查询数据。我不担心在MySQL中放很多记录——它的伸缩性非常好

在这种设计中，您需要在查找表中将“门户”映射到“酒店”：

门式酒店

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