我们正在为我们的内部应用程序创建新策略。我们目前有大约10-15个应用程序直接针对相同的数据库。这显然不是很好，我们想评估我们的选择。至于我可以看到，我们必须选择：针对单一数据库架构的多种应用程序
我非常希望听到你对此的反应。我相信第二个选择是要走的路，这也给了我们一个实现缓存的有效层。但是，你将如何为所有应用程序公开这个图层？ Web服务/休息是否会走，或者还有其他更好的方法来做到这一点？
我认为这个流行语的答案是“面向服务的架构” - 这确实是选项2。
这是一个大规模的事业，有许多令人兴奋的死角来探索 - 但基本上，而不是考虑数据库和表，考虑这15个应用程序需要的服务。有些可能是共享的，有些可能是特定于一个应用程序的。找到一种将这些服务暴露给应用程序的方法 - 但请记住，Web服务调用可能比等效的直接数据库调用慢得多，所以不要将“面向服务的体系结构”表示为必须在任何地方引入Web服务 - 它比产品规格更具有心态。
复制和同步 - 以我的经验 - 创建非常脆弱的系统，失败模式会伤害大脑甚至想到。
其他 - 呃，你实际上并没有说明你想要解决什么具体问题。如果它的性能 - 提供性能问题的最便宜的方法是在硬件上解决问题。如果它具有可管理性 - SOA可以帮助实现这一目标 - 但它通常还会将更多基础设施引入混合中，这也需要维护。确保你确实清楚推动你的架构选择的因素，因为没有单一的“最佳”解决方案 - 这完全取决于折衷。
我看不出为什么10-15个应用程序必须共享一个数据库？真的所有的应用程序都必须使用所有表吗？
首先将所有对每个应用程序唯一的表移动到单独的数据库中。
完成后，应该很容易看出多个应用程序访问同一个数据库是否会有问题。通常这并不重要，除非应用程序开始缓存数据（因为您永远不知道其他应用程序是否更新了缓存的某些数据）。最典型的方法是为此使用某种消息。
分析的选项你揭露：
复制数据库，并使用复制等进行同步
让他们如果所有的应用程序需要访问同一个数据库，我觉得复制这是一个糟糕的决定，因为你会面临同步问题（过时的数据等）。
在数据库和顶层的10-15个应用程序之间创建一个新的应用程序。
这确实是一个很好的可能性。如果您不希望所有这些应用程序依赖于数据库的实现细节（例如，对一个表的更改会影响所有这些应用程序的代码），则可以将数据库“隐藏”在提供“对这些“客户端应用程序”的业务有意义的操作。
如果您刚刚面临性能问题，我会建议将数据库集群化（而不是手动复制）。
一个未提及的选择是在存储过程/触发器等有一部分逻辑...不是一个好主意，但一个想法不是那么少。
我想说你的第二个选择是这里最好的选择。如果你在.NET平台上，WCF是一个非常简单而强大的方法。
我们已经遇到了大量的数据库逻辑问题，这使得维护起来非常困难，同时也造成了很多难以理解的问题。通过在数据库顶部添加一个图层，我们的计划是将这些逻辑提取到代码中。 – femseks
是的，我会强烈反对数据库中的任何逻辑，这是程序性的，繁琐的，分散的，很难维护的。暴露数据库的图层实际上是您唯一真正的选择。 GL –
好吧，这是复杂的，因为这是旧的和新的应用程序的组合。这个数据库包含所有的客户数据，所以提取独特的表格并且大多数表格被两个或更多的应用程序共享将会是一项巨大的工作。 消息传递的方法是绝对讨论，但我没有看到任何“简单”的方式来实现这一点，而几乎没有开始。 – femseks
是的，这是一个巨大的工作。当你有5或10个以上的应用程序时，你认为它会是什么？ – jgauffin
我在2个数据库中维护了5个应用程序。有些相当复杂。一旦我熟悉了代码，我就打开了MS Visio，并自动创建了每个数据库中所有表格的图表。然后我通过功能将表格尽可能分组，并将颜色编码块放在每个分组周围。我不仅结束了对数据库的更好理解，还发现了甚至没有使用的表。它还使添加新功能变得更加容易。 – Raystorm