RDBMSを使う場合、データ中心にモデリングし、SQLで業務に向けたビューを提供するという手法が一般的です。
で、Google App Engineのようにバックエンドが分散KVS（NoSQL）になる場合、SQLが使えないので、導出値は頑張ってロジックで計算するか、更新時にあらかじめ計算して保存しておく必要があります。
どちらかといえば後者の「更新時にあらかじめ計算して保存しておく」という方法が一般的かと思いますが、この方法を採用する場合、データモデルだけでなく、アプリケーションの機能を最初に洗い出しておく必要があります。また、あとから導出項目を表示項目として追加する場合のインパクトもRDBMSを使う場合と比べると大きくなるように思います。また、そのたびにデータ移行も必要になります。
というわけで、データ中心に設計する場合と比べると事前に決めておかなければならない部分が多く、さらに追加や手戻りのダメージが大きいとなると、そういうデメリットを差し置いてまでスケールアウトすることが必要なアプリケーションでしか分散KVSを使うメリットはないわけです。少なくとも、いわゆる業務アプリケーションの分野ではメリットよりもデメリットのほうがまだかなり上回っているような気がするんですよね…。
CPUとメモリはスケールすると考えると、前者の「都度ロジックで計算する」という方法もあながち間違っているとは言えませんが、それだとCOBOLの時代に逆行しているようなものですし…。
僕の頭が固いだけなのかもしれませんが、実際にGoogle App Engineを使っていて上記のような点について疑問を持っています。このようなデメリットを回避、もしくはパラダイムをシフトするようなうまいやり方があるのでしょうか。
