こんにちは！
今回のテーマは、「ユーザーのストレスが減るソートの作法」です。
FileMaker（ファイルメーカー）よく使われるスクリプトステップにソートがあります。ソートとは、レコードをある基準に従って並び替えることです。
このソート、使い方を間違ってしまうとユーザーにとってストレスがたまる、使いにくいアプリになってしまうかもしれないので注意が必要です。
初心者がやりがちなソート
ソートのスクリプトステップの設定はそれほど難しいものではありませんが、逆に言うとそれがネックになる場合もあります。
まずは、スクリプトの内容がこれだけの場合です。
レコードのソートでエラーが起こることは稀ですが、エラー処理（オン）くらいは入れておきましょう。個人で使うようなものではない限り、業務で使用するアプリのスクリプトには、エラー処理を入れておきましょう。このエラー処理がない場合、ユーザーがスクリプトを停止できてしまう可能性もあり、セキュリティ上リスクにもなります。ユーザーによる強制終了を許可ステップを入れておくことでも対応できますが、一瞬で終わるスクリプトでは、その余地はないので入れなくても大丈夫だとは言えます。不安なら、入れておいてもいいでしょう。
ストレスがたまるソート
レコードの移動のステップを入れておきましょう。
ソートを行うと、元々フォーカスされていたレコードはそのままにソートされることになります。検索実行によって対象レコードを絞ったばかりだと、一番上にフォーカスされていますが、ソートすることによって、どこに行くかわかりません。これが、下の方へ行ってしまうとソートした意味が半減してしまいます。
かならず、ソートした後は、レコードの移動のステップを入れておきましょう。
ソートは負担のかかる作業だという認識
ソートは、FileMakerの中でも負担のかかる作業だという認識は必要です。一昔前に比べれば、FileMaker事態のパフォーマンスアップによってあまりそれを感じられなくなってはいますが、それでもどちらかというと気を使っておいた方がいい処理には違いありません。
ですから、その中でもソートに時間がかかると感じたら、工夫をすることが必要です。
関連レコードのソートはやめる
FileMakerの中で、どの処理もそうですが、関連レコード（リレーションシップ先のテーブル）の処理をすると時間がかかる傾向にあります。
ですから、できるだけ関連レコードはソートの条件に含めないことが重要です。
どうしても含めたい場合は、ソート対象のテーブルにそのレコードを入れてしまうことを検討しましょう。
例えば、このような構成があるとします。社員のテーブルには、部署名が保存されていません。もし、部署名で検索をしたいときは、部署のテーブル（関連レコード）をソートのキーに入れなくてはいけません。
実際は、この程度であれば、パフォーマンスに影響を与えることは少ないかと思いますが、下記のようにしておくこともできます。
社員のテーブルに部署名も含めれば、リレーションシップ先をソートに含めなくてもすみます。これは検索する場合にも同じことが言えますので、ぜひ覚えておきましょう。
