我目前正在为大约90 KLOC的保险经纪人开发一个数据库密集型的业务线Rails应用程序 - 大多数是通过业务交易进行数据处理，以及汇总所有数据的多个报告。 / p>
我们是一个非常小的团队，代码库的大小和复杂性开始超过我们管理它的能力。正因为如此，我们正在研究如何驯服它，其中之一就是将其转换为面向服务的体系结构 - 即将其拆分为几个较小的应用程序。
该方法的问题在于报告方面：我们的报告通常涉及最多7个连接的表，过滤器在此过程中作用于多个表。如果我们放弃服务共享表的可能性（在多篇文章中说明是反模式），是否有可能以不会影响性能的方式加入所有这些数据？
那么，SOA是针对这类问题推荐的方法吗？或者它带来的问题多于解决的问题？
虽然我们的专长主要在于Ruby（Rails和Sinatra）和Python（Plone和Grok），但我还想知道围绕其他技术（.NET，Java）的社区通常如何处理这个问题。
提前致谢！
答案 0 :(得分：1)
我来自数据仓库背景，并对ruby / rails保持兴趣。 阅读您的帖子后，我感觉您的报告架构可能需要重新设计，并且要远离基础系统。
重新设计该段后，您的原始系统可能不会那么大/复杂。
简而言之，通过7个级别的加入的报告要求让我觉得“尴尬”，看起来您正试图使用您的交易系统进行报告？
我建议您使用预先计算的聚合移动到不同的架构/数据库（当然杠杆将取决于您的业务案例）。这应该有助于降低基本系统的复杂性，并允许您更快，更相对简单的报告环境。您可能会产生一些存储成本（对于aggs env的单独db / schema），但这应该是为简单/设计付出的小代价。
HTH
答案 1 :(得分：1)
SOA确实可以帮助您保持受尊重服务的代码库更小并且更好地分离。它还将简化您的运营数据库，因为每个服务的数据库将被分开。不利的一面是，它不适合报告。
另一方面，正如learn4living所指出的那样，无论如何，您可能最好使用单独的模式进行报告，因为操作数据库不便于报告，非规范化数据更易于使用。
我在aggregated reporting周围调用了这个模式，你可以在几年前的bridging the gap between BI and SOA上阅读我写的一篇文章
答案 2 :(得分：1)
SOA，批处理和缓存的组合将在很大程度上解决您的问题。您需要确定哪些流程
为了长期利益而投资一些非规范化也可能值得你花时间。