『売上猫くん on MySQL』開発日記 - 番外19 - FMで大きなSQLテーブルは扱えるのか？ ― その4

前回は、FM社製のドキュメント（日本語版と英語版）内の一文を引用し、それを小生なり解釈すると「他のフロントエンド開発ツールに比べるとFileMakerのESSはかなり限定されていること、また一見してFileMaker単体のシステムと同じ結果を返すように見えても異なることがある。ユーザはESSの限界と特性を意識して使用すべし」となる旨のことを書いた。これに加えて、同ドキュメントにもう一つ気になる文章がある。

ESS は、FileMaker Pro ソリューションを、FileMaker Pro のみをベースにしたソリューションの限界を超えてスケールアップできる手段として設計されたものではありません。(ESS is not designed as a means to allow a FileMaker Pro solution to scale beyond the limits of a purely FileMaker Pro based solution.)

この一文は何のことを言っているのか？　この日記番外シリーズにも書いたように、FileMakerソリューションであっても、当然ながら、SQLデータベースの多くの機能---ビュー、ストアドプロシジャ、トリガ、ログ照会、バイナリ/トランザクションログからのリカバリ等----FileMaker純正データベースエンジンでは不可能だった機能の恩恵に浴せる。この場合、主語を“ESS”ではなく“FileMaker”にすれば、「FileMaker Pro のみをベースにしたソリューションの限界を超えてスケールアップできる」のである。

とするとこの文は、「FileMaker純正データベースエンジンが実用的には（“論理的”にではない）取り扱うことができない大きなテーブルをSQLデータベースのそれに置き換えても、やはり実用的には取り扱うことはできない」と言っているのだと思われる。　タイトルにある「 FMで大きなSQLテーブルは扱えるのか？」という命題への直接否定のようだ。

直接否定だとすると、FileMakerの理論上、仕様上の限界はデータベース単位で8TBであるが、実用上の“限界”はどのくらいなのだろう？　古い記事だが、「（個人的な意見だがテーブルベースで）100万を超える位なら大丈夫だよ」とある。　小社でも数十フィールドあるFileMakerテーブルに100万～200万弱のレコードを収納して数年間、運用している。　200万レコード程度をFileMakerの“限界”と仮定すると、その“限界”を超えて、と主張するには、レコード件数的には400万レコード以上をテスト時の最大数とすれば十分だろうか。ちなみに、『売上猫くん on MySQL』のテスト環境で、いまのところ一番大きなテーブルのレコード数は約180万件である。

ただレコード件数をいくら増やそうとも、ユーザが強いストレスを感じたり、安定性が無いシステムでは“実用的”とは言えない。　“実用的”と言うには、その1とその2で書いたような問題をできる限り顕在化させてはいけない。問題6の激遅ソートは回避策がないので、ユーザによるカスタムソートの実用性は非常に低い。　その他の問題については、回避策を施したり、　運用で調整する（例えば、.fp7ファイルをサーバ上に置かず、ローカルに置く）ことにより、緩和できるものと判断している。　だが結局、「FileMaker Pro のみをベースにしたソリューションの限界を超えてスケールアップでき」たかどうかというのは、公正なエンドユーザの判断に拠る、としかいいようがない。

（土屋）

注：
「～限界を超えて～」については、上記の英文をキーにググってみたが（その3の参考URLを参照）、2007年当時は否定的な見方が優勢だった。　2008年以降は関連する記事を見つけることができなかった。


関連リンク：『売上猫くん on MySQL』開発日記の記事一覧