FileMakerが重い・処理が遅いと言われる理由

ファイルメーカーは決して全体が遅い訳ではありません。むしろ速い処理が出来る部分もあります。

「ファイルメーカーは遅い・重い」は誤解?

FileMakerが重い・処理が遅いと言われる理由決してファイルメーカー自体の能力が低い訳ではありません。

全体的に遅くはないのですが、ファイルメーカーの構造を理解しないで構築してしまったり、無理難題を受けすぎて最初の設計思想とはかけ離れた機能追加をしてしまうことで、結果的にまったりとしたものが出来上がってしまいます。

ファイルメーカーの長所・短所を理解して、より現場で効果的に使えるシステムを構築できるようになりましょう。

ファイルメーカーの長所・メリット

まずはメリットを書き連ねていきます。何を使うにしても長所短所は存在します。
そこを理解して初めて、ファイルメーカーの機能を最大限発揮できるシステムを構築することができます。

ユーザーフレンドリーな操作

  1. 入力・データ更新
    デフォルトでは入力する際に、フィールドを変更したら即座にデータ更新してくれます。
    エクセルなど上書き保存せずに閉じてしまうと入力したデータが飛んでしまいますが、ファイルメーカーは都度都度フィールド単位で保存してくれるので、ユーザーが慣れてしまえば非常に入力効率のよいアプリケーションと言えるでしょう。
  2. 検索の使いやすさ
    大量のデータの中から適切なデータを検索していくのも重要な機能の一つです。
    ファイルメーカー自体が持つ検索機能は非常に便利で高速です。
    更に、デザインの通りに「検索モード」「ブラウズモード」が切り替わってくれるので、ユーザーはどのフィールドに格納されているなんというデータを検索したいかが直感的にわかります。

開発者にも優しい

  1. 開発期間の短縮・効率的な開発
    開発者は余計な機能を作る必要がありません。
    例えば、Webアプリケーションを作るとなると様々な知識が要求され、更に多くの機能を自前で実装していかなければなりません。
    しかしファイルメーカーは検索機能もあるし、帳票類の印刷レイアウトもA4など紙のサイズにもともと合わせられているので、より現場に則した機能だけを作ることに集中できます。
    その結果、開発期間は非常に短縮できるのが特徴です。
  2. 直感的で多くの知識を必要としない
    もちろん、リレーショナルデータベースとはなんぞや?ということを理解していないと開発は難しいですが、それも管理画面のリレーションではそれぞれのテーブル間でどのフィールドを関連付けるかがGUIで操作でき、ドラッグアンドドロップだけで関連性を作れます。
    フィールドの種類もそこまで多いわけではないので、型宣言という概念よりはそのフィールドに何を入力していくかをしっかり押さえていればプルダウンから選ぶだけでフィールドはどんどん作れていきます。
  3. クライアントサーバー型のメリット
    サーバーがファイルメーカーのファイルをホストして、各PCにインストールしたクライアントが閲覧しにいくようになっているため、管理者はホストされているサーバーの管理とファイルだけを運用していけばほとんど問題ありません。
    企業ではあまりないとは思いますが、Webアプリケーションの場合ブラウザによってCSSやjavascriptの解釈が異なるため、ブラウザ毎に調整する必要がありますが、ファイルメーカーはファイルメーカーだけなので一点集中して開発運用ができます。

ファイルメーカーの短所・デメリット

良い点だけ抑えておけば良い物が作れる訳ではありません。
むしろ悪い点を把握してこそ、そこを回避しながらシステム構築しなければなりません。

開発者はしっかりと理解しなければいけないファイルメーカーの仕組み

  1. アプリケーションとデータベースが一体になっている

    これは一見良いように聞こえます。
    確かに良い点はあるのですが、理解しないととんでもなく遅いシステムとなってしまいます。

    データベースを大きく捉えると、

    • ユーザーインターフェース(UI)
    • 各種処理のロジック
    • データを保存するデータベース(DB)

    となるでしょう。
    ここは出来ればそれぞれが独立しているとどこに処理を集中させて、負荷分散させようかという設計ができますが、ファイルメーカーの場合は基本的にリレーションと計算フィールドに依存してしまいます。
    それは、リクエストが発生した際に処理するのはDB(フィールド)でありロジックがデータベースにくっついてしまっているからです。
    ここを充分に理解しないまま開発を続けると、無駄な計算フィールドだらけになり、検索もキャッシュできないため遅い検索となり、最悪の場合サーバーでホストしているファイルがクラッシュしてしまいます。

  2. スクリプトの遅さ
    それなりの規模になってくると、スクリプトを使ってユーザーに負荷をかけないようにしなければなりません。
    しかしファイルメーカーのスクリプト実行速度は決して期待出来るほどではないということです。
    例えば、ある条件のレコードを抽出して該当するフィールドの値をレコード毎の値を元に処理して結果を別フィールドに保存する、ような処理をスクリプトで処理すると、実際に画面通りに処理が走ります。
    これはバックグラウンドで処理してくれればいいのですがファイルメーカーの仕様上仕方ありません。
    人間が操作するのと同じ様に、検索し絞りこまれたレコードが表示され1レコードあたりの処理が終わると次のレコードをめくって処理を続けるからです。
  3. リレーションが深いポータルやフィールドの検索は危険
    これは検索モード時にフィールド選択をできないようにしましょう。アドミンコンソールから危険な検索をしたユーザーを切断しても切り離せず、システム全体がフリーズしホストしているファイルが破損します。
    この場合サーバー側で、ファイルメーカーサーバーのサービスを停止しOSを再起動させ、ファイルメーカーサーバーのサービスを開始させるとデータベースの検証が開始されます。破損具合にもよりますが数時間は使えなくなります。
    これらを回避するにも深いリレーションは検索させないのが回避策のひとつになります。
  4. ファイルメーカーサーバーのメモリ消費
    結構消費します。
    運用していたものは仮想サーバーでしたので、メモリ増減は簡単に行えましたが物理サーバーで運用するとなるとスロット数に注意しなければなりません。しかもメモリも高いので社内決裁など手順を踏むことになるでしょう。そうするとスピーディーな運用ができなくなります。
    ちなみに、WindowsServer2008で10GBのメモリ(RAM)にし、別ドライブを追加して仮想メモリを利用していました。
    それでも大きめな規模のシステムになったので、レスポンスを確保するのにハードウェアからしっかりと運用・管理できないと難しくなってきます。

ファイルメーカーのメリット・デメリットを理解して快適なシステムを構築する

ここに上げたメリット・デメリットは特徴的な一部に過ぎません。
ただ私が運用上経験したものを上げているので、少なからず応用できると思います。

これらの良くも悪くも特徴を理解してユーザーに不満を抱かせないシステム構築をしてみてください。

コメントをどうぞ