PR

 ここでは四つの案を示したいと思います。

方法1:フラット・ファイルでも容易に実装可能なデータアクセス・インタフェースを設定

 レジ・アプリケーションではデータアクセス層に共通インタフェースを設定し,その実装部分に実行環境の違いを閉じ込めました。この考え方をそのまま集計アプリケーションに適用したのが方法1です。フラット・ファイルにはSQLを利用できませんので,設定できる共通インタフェースは「getRecordNext」(データを1件ずつ順番に取得)といった単純なものにならざるを得ません。これならフラット・ファイルであっても容易に実装できます(図4)。

図4●データアクセス層で共通インタフェースを設定する方法
図4●データアクセス層で共通インタフェースを設定する方法

 ただ,この方法には大きな問題がありました。RDBMSを用いても処理性能が低くなることです。実装したい機能は,「その日に売れた商品の売り上げトップ10を一覧表示する」といったものです。しかし,getRecordNextといった単純なインタフェースだと基本的なSQLのみで実装できるので,高度なSQLは使わないでしょう。つまり,高速処理が期待できないということです。

 売り上げトップ10といったデータを得るには,getRecordNextというインタフェースから取得したデータを集計してソートし,その上位10個を取り出すといったことを記述することになります。そうしたプログラムは複雑になりがちで,処理性能も低く,また,作り方が悪いと不用意に大量のデータをメモリー上に展開して「OutOfMemory」(メモリー不足)といったエラーを引き起こしかねません。

 こうした処理は意味的にはデータアクセス層に相当すると思われますが,共通インタフェースを呼び出すのはビジネスロジックですから,データの集計やソートはビジネスロジックの中に組み込まれることになります。ビジネスロジックにデータアクセス層の処理が混在するのは避けたいところです。

方法2:ビジネス機能に結びついた共通インタフェースを設定

 この方法は,方法1のデメリット(RDBMSを利用できる環境であっても高度なSQLを利用できないこと)を解消するために考えたものです。共通インタフェースを変更して「売り上げトップ10を取得」といったものにすれば,そのインタフェースのRDB用実装には高度なSQLを利用でき,処理性能の問題を解決できます(図5)。フラット・ファイル用実装ではデータの集計やソート処理を記述することになりますが,フラット・ファイルに特化して(余地があれば)思い切った最適化を図ることができます。

図5●ビジネス層で共通インタフェースを設定する方法
図5●ビジネス層で共通インタフェースを設定する方法

 ただ,この方法にも大きな問題があります。「売り上げトップ10を取得」といったインタフェースはビジネス機能に依存することです。つまり,ビジネス要件が変わればその影響を受け,共通インタフェースとその実装を修正しなければならなくなります。この共通インタフェースは意味合い的にはビジネス層に含まれますので,ビジネスロジックの開発チームとデータアクセス層の開発チームがそれぞれ独立して開発する,といったことは難しくなります。