データ量が多いシステム
FileMakerのC/S環境における特性
この件の予備知識として、C/S（クライアント・サーバ型）環境におけるFileMakerのある便利な特性について触れておきます。
例えば、「郵便番号簿」のマスターにある特定の同一レコードを、2人のユーザーが画面に表示していたとします。この時、一方がデータの一部を変更すると、当然、変更した側の画面は新しい情報に更新されますが、もう一方の画面ではどうなっているでしょうか。
一般的なC/Sシステムでは、［更新］ボタンなどの明示的なアクションにより、再度SELECT文を発行して、最新情報を取得することになると思います。ところがFileMakerでのC/Sシステムでは、そのような明示的な操作を行わなくとも、表示されている画面の情報が最新の内容に変更されます。
簡単に説明すると、データの変更内容を受け取ったFileMaker Serverが、その情報を各クライアントに向けてほぼ即時に配信します。配信対象は、「その情報を画面上に表示している」クライアントです。
「その情報を画面上に表示している」という部分を念頭に置いて、以下の話を読み進めてください。
ネットワーク上でのデータの流れ
さて、扱うデータ量が非常に多くなった場合、考慮する点の一つに「データ取得時の反応速度」があります。
この速度を左右する大きな要因の一つが、ネットワーク上を流れる「データの量」です。呼び出し対象のデータや利用者に比例して増大します。システムの反応速度を保つならば、この「流れるデータ量」が増えないように工夫する必要があります。
先述のように、FileMakerではクライアントが画面で表示している項目が、データ取得の対象となり、常にそこに向けてデータが配信されます（逆に言えば、その項目を対象にしたリクエストが常に投げ続けられています）。従って、表示しているレイアウトの項目数が多ければ多いほど、流通するデータ量も多くなります。
画面構成の簡易さから、特に意識せず無造作に項目を並べていくと、情報が見づらくなるだけでなく、トラフィックに余計な負担をかけることになるので、注意した方が良いでしょう。
ただ、逆に「画面に表示されていない項目はデータが流れてこない」と考えることもできます。さらに言うと、レイアウト上には配置されている項目でも、ウィンドウの表示サイズの外側にある項目は、画面をスクロールして表示されるまでデータが流れません。
これについては、下記の資料を参照してください。
検索を行った後の一覧表示と、その際にネットワーク上を流れたデータをキャプチャしたものです。
図3～4は、検索にヒットした件数が62件で、そのうち51件を画面に表示しています。図5～6は、図3～4と同じ検索を行いますが、ウィンドウの高さを狭め、画面に表示されるレコード件数を少なくしています。両方とも検索結果の件数は同じですが、流れているデータ量が異なることが分かります。
レイアウトに不必要な項目を配置するとトラフィック増加の要因となるため、画面構成をデザインするに当たっては意識したい部分です。
