集計をおこなう、もうひとつの選択肢 - 中間テーブル

計算フィールドも集計フィールドも、結果の表示には内部で計算処理がおこなわれる。レコード数が多ければ多いほど、パフォーマンスに甚大な影響が出るのは前回紹介したとおりだ。

これら2種類のフィールドを使わずに集計値を出す方法として、集計結果を保存するためだけのテーブルを用意し、そこに随時集計の計算結果を書き込むという方法がある。ここではそのテーブルを便宜上「中間テーブル」と呼ぶ。

中間テーブルにはあらかじめ「集計の切り口」を考慮した設計・実装をおこなっておき、最初の段階で必要なレコードをすべて作成しておく。集計したいテーブルにレコードが登録/編集/削除される度に計算をおこない、結果を中間テーブルに保存しておく。レコードの登録/編集/削除処理にわずかなコストが発生するが、つねに集計結果を中間テーブルで持っていることになる。集計値を表示したい場合は中間テーブルの値を取り出すだけなので、大幅なパフォーマンスアップを見込めるのだ。

集計をおこないたいテーブルと、中間テーブルの関係イメージ図。集計結果を中間テーブルに数値フィールドとして保持しておくことで、計算フィールドや集計フィールドを使わなくとも集計値を算出することが可能となる

前回の場合は全レコードの集計値がほしいだけなので、中間テーブルに用意しておくのは1レコード。そして集計値を保存する数値フィールドだけだ。実際にFileMakerでテーブルを構築してみよう。集計に使用するテーブルは、前回使用した100,000件のレコードが格納されているテーブル「summary_test_100000」をもちいる。

中間テーブル「summary_join」に用意したフィールド。シリアルナンバや登録日時/変更日時のほかに用意したのは数値フィールド3つだけ

集計をおこないたいテーブル「summary_test_100000」と、中間テーブル「summary_join」のリレーション。今回は全レコードの集計値がほしいので、リレーショナル演算子は「x(照合フィールドの値に関係なく、左側のテーブルのすべてのレコードを右側のテーブルのすべてのレコードに一致させる)」としている

もちろんこのままでは自動的に集計値を保存してくれないので、FileMakerスクリプトを用意する。ここで気をつけるのは「Web公開に対応したスクリプトステップで実装をすること」だ。

FileMakerスクリプト「new_summaryToJoin」。レコード登録時に集計の計算をおこない、結果を中間テーブルに転記

ここでも計算に集計フィールドを使用するのではなく、中間テーブルの値に差分結果だけを渡すようにしておくことがポイントだ。さらにすべてWeb公開に対応したスクリプトステップで実装することで、FileMaker ProからもWebアプリ側からも利用できるFileMakerスクリプトとなる。レコードの登録時にこのスクリプトを実行して、集計結果をつねに中間テーブルに保存させるように。集計値を表示したい場合は中間テーブルの数値フィールドを表示するだけだ。あらかじめ集計結果を中間テーブルに代入した上で前回とおなじ条件でレイアウトを組み、どれほどパフォーマンスがあがっているかを確認してみよう。

% ab -n 10 -c 1 -A admin:admin "http://localhost/fmi/xml/FMPXMLRESULT.xml?-db=fm_tune.fp7&-lay=(レイアウト名)&-max=1&-find"

前回の集計フィールドを使用したTime per requestと、中間テーブルを使用したTime per requestを比較してみよう。

  配置した集計フィールドの数
  1 2 3
100,000レコード
(集計フィールド)		 6117.105 [ms] 7369.087 [ms] 8597.461 [ms]
100,000レコード
(中間テーブル)		 17.713 [ms] 17.729 [ms] 18.319 [ms]

ただ数値フィールドを取得するだけなので、集計フィールドを使用したときとは比較にならないほどパフォーマンスがあがっている。集計値は数値フィールドなので、要件に応じてソートや検索もパフォーマンスを落とすことなく実現することが可能になるのだ。

中間テーブルは万能にあらず。使用する前に場面を見極めて

パフォーマンスアップのための切り札とも呼ぶべき「中間テーブル」だが、この案は万能ではない。メリットとデメリットを比較してみよう。

メリット

  • 計算/集計フィールドを使用しないため、非常に高速。理論上レコード数が増えてもパフォーマンスは落ちない
  • ソートや検索も計算/集計フィールドを比較すると高速に動作する

デメリット

  • あらかじめ決められた切り口でしか集計できない。あとから集計の切り口を変更したい場合、集計フィールドを使用する場合よりも修正の工数がかかる
  • 中間テーブルで保持するレコードの分だけ、ファイルサイズの容量がかさむ
  • 集計結果を保存するFileMakerスクリプトにバグがあった場合、修正作業時にただしい集計値を出すために手動での計算が必要となる

中間テーブルは初期の設計・徹底した検証があってこそ強力な武器になる。開発初期の段階では集計フィールドをもちいた実装をおこない、運用が安定期になったところで中間テーブルへの移行をおこなうのがスムーズかつ安全な進め方だろう。使いどころを見極めて、強力なFileMaker Webアプリを作成しよう。次回以降、この中間テーブルについて、PHP側での利用をふくめたアドバンスドな使い方を紹介する。