多个应用程序针对单个数据库架构

Question

我们正在为我们的内部应用程序创建新策略。我们目前有大约10-15个应用程序直接访问同一个数据库，这显然不是很好，我们希望评估我们的选择。据我所见，我们有两个选择：

1. 复制数据库并使用复制等方式使它们保持同步。 2. 在数据库和这些10-15个应用程序之间创建一个新的应用程序层。

您对此有什么想法？我认为第二个选项是正确的选择，这也为我们实现缓存提供了有效的层。但是，您将如何向所有应用程序公开此层？Web服务/REST是否是正确的选择，还是有其他更好的方法？

- femseks

Answer 1

我认为这个问题的流行答案是“面向服务的架构”，也就是选项2。

这是一个大规模的工作，有许多令人兴奋的死胡同可以探索。但是基本上，不要考虑数据库和表格，而是考虑那15个应用程序需要的服务。有些可能是共享的，有些可能是特定于一个应用程序的。找到一种将这些服务暴露给应用程序的方法，但请记住，Web服务调用相对于直接数据库调用可能会慢得多，因此不要认为“面向服务的架构”意味着您必须在所有地方引入Web服务-它更多是一种思维模式而不是产品规范。

在我的经验中，复制和同步创建非常脆弱的系统，并且故障模式令人难以忍受。

其他-好吧，您实际上没有说您要解决的具体问题。如果是性能-解决性能问题的最便宜方法是为问题投入硬件。如果是可管理性-SOA可以帮助解决这个问题-但它通常还会将额外的基础设施引入混合中，这些基础设施也需要维护。确保您真正清楚您的架构选择的驱动力，因为没有单一的“最佳”解决方案-这全部取决于权衡。

- Neville Kuyt

Answer 2

分析您公开的选项：

复制数据库并使用复制等方式将它们同步

如果所有应用程序都需要访问同一个数据库，我认为复制它是一个糟糕的决定，因为您将面临同步问题（过时数据等）。

在数据库和10-15个应用程序之间创建一个新的应用程序

这确实是一个很好的可能性。如果您不希望所有这些应用程序依赖于数据库的实现细节（例如，一个表的更改会影响它们所有代码），则可以将数据库“隐藏”在一个应用程序后面，该应用程序向这些“客户端应用程序”提供“业务有意义”的操作。

如果您只是面临性能问题，我建议将数据库集群化（而不是手动复制）。

- Mr.Eddart

Answer 3

我不明白为什么10-15个应用程序必须共享一个数据库？难道所有应用程序都必须使用所有表格吗？

首先，将每个应用程序所需的唯一表格移动到单独的数据库中。

完成后，很容易看出多个应用程序访问同一数据库是否会有任何问题。通常情况下并没有关系，除非应用程序开始缓存数据（因为您永远不会知道另一个应用程序是否已更新了您缓存的某些数据）。最典型的方法是使用某种消息传递方式。

- jgauffin

---

这很复杂，因为它是旧应用程序和新应用程序的混合体。该数据库包含所有客户数据，因此提取唯一表格将是一项巨大的工作，而且大多数表格由两个或更多应用程序共享。消息传递方法正在讨论中，但我没有看到任何“简单”的实现方式，几乎需要重新开始。 - femseks

是的，这是一项巨大的工作。如果您有5或10个以上的应用程序，您认为会是什么情况？ - jgauffin

我曾经在两个数据库中维护了5个应用程序。其中一些相当复杂。一旦我熟悉了代码，我打开了MS Visio，并让它自动创建了每个数据库中所有表的图表。然后，我尽力按功能对表进行分组，并在每个分组周围放置了彩色编码的块。最终，我不仅对数据库有了更好的理解，还发现了一些未被使用的表。这也使得添加新功能变得更加容易。 - Raystorm

Answer 4

一个未提及的选项是将部分逻辑放在存储过程/触发器等中...虽然不是一个好主意，但仍然是一个想法。

我认为你的第二个选项是最佳选择。如果你使用的是.NET平台，WCF是一种非常简单而强大的方式。

- Denis Biondic

---

我们已经面临着严重的问题，即数据库中有大量逻辑，这使得维护非常困难，也会导致很多难以理解的问题。通过在数据库顶部添加一层，我们计划将其中一些逻辑提取到代码中。 - femseks

是的，我强烈建议不要在数据库中使用任何逻辑，它是过程式的、笨重的、分散的，并且非常难以维护。一个暴露数据库的层实际上是你唯一真正的选择。 - Denis Biondic