1

我正在使用的系统结构如下。鉴于我打算使用 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，会不会因为记录的数量而对系统来说很麻烦？

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

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

4

2 回答 2

2

您描述的问题是“多租户” - 这是一个相当棘手的问题，但幸运的是，其他人已经写了一些有用的方法。（虽然链接指向 Microsoft，但它适用于大多数 SQL 环境，但详细信息除外）。

在您的情况下，权衡是：

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

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

在这样的设计中，您可以在查找表中将“门户”映射到“酒店”：

门户酒店访问

PortalID   HotelID
-----------------
A          X
B          X
B          Y
C          X
C          Y
C          Z
于 2012-11-27T10:57:23.507 回答
1

我可以建议两种方法。选择哪一个取决于有关整个系统的一些附加信息。事实上，主要问题是您的系统是否可以从消费者的角度（a、b、c 等）冒充（在法律上自行替代）任何数据提供者（x、y、z 等） .

集中式数据库

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

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

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

多个本地数据库

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

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

这种变体与当今大多数 Web 应用程序的工作方式非常相似，实现起来更简单，但更容易出错。

于 2012-11-27T10:41:49.487 回答