我目前正在爲保險經紀數據庫重，業務線-Rails應用程序也就是大約90 KLOC - 大部分是通過商業交易數據處理，以及多份報告彙總所有這些數據。分崩離析數據庫重應用
我們正處在一個非常小的團隊和代碼庫規模和複雜性也開始長大了我們管理IT容量。因此，我們正在研究如何馴服它，其中之一就是將其轉換爲面向服務的體系結構 - 即將其分解爲幾個較小的應用程序。
與方法的問題是在報表方面：我們的報告通常涉及的是高達7加入路程，作用在沿途多個表過濾器表。如果我們放棄服務共享表（在多篇文章中聲明是反模式）的可能性，是否有可能以不損害性能的方式加入所有這些數據？
那麼，SOA是這種問題推薦的方法嗎？還是它帶來了比解決問題更多的問題？雖然我們的專業知識主要集中在Ruby（Rails和Sinatra）和Python（Plone和Grok）上，但我還想知道圍繞其他技術（.NET，Java）的社區通常如何處理這個問題。
在此先感謝！
我來自數據倉庫的背景，並保持對ruby/rails的一些興趣。 閱讀您的文章後，我感覺您的報告架構可能需要重新設計，並且要從基本系統中分離出來。
隨着該部分重新設計，或許您的原始系統不會太大/複雜。
概括地說，通過7級的進了報告要求加入讓我覺得「彆扭」，貌似你試圖使用你的交易報告制度？
我建議你移動到一個不同的模式/數據庫預先計算的骨料（當然槓桿將取決於你的商業案例）。這應該有助於降低基本系統的複雜性，並且可以讓您的報告環境更快，更簡單。您可能會產生一些存儲成本（針對aggs env的獨立數據庫/模式），但這對於簡化/設計來說應該是很小的代價。
心連心
SOA確實會幫助你保持更小的尊崇服務的代碼庫和更好的分離。它還將簡化您的運營數據庫，因爲每個服務的數據庫將被分開。當然，缺點是它不適合報告。
在另一方面，作爲learn4living指出的，你可能有一個單獨的模式更好，因爲對業務數據庫都不方便的報告和非規範化的數據更容易使用無論如何報告。
我把這個aggregated reporting周圍的模式，你可以讀到一篇文章我幾年前寫了這件事，就bridging the gap between BI and SOA
SOA，批處理的組合和緩存將解決您的問題，在很大程度上。您需要確定哪些進程
它也可能是值得的，同時投資於非規範化位爲長期受益。
這是否意味着對這兩種服務使用共享數據庫方法？我無法想象兩個數據庫之間的同步會如何發生......我在這方面是一個新手，你能指點我一些資源嗎？ –
這將有一個用於事務處理目的的db1，可能還有用於報告目的的db2（或schema2）。您需要根據報告要求構建一些用於填充db2/schema2的集合生成代碼。 – Gyan