FileMakerの集計は遅くないよ！

その前に。。

シリアルNOの初期値化と欠番

のダウンロードを再開しました。

が、注意が必要です。

SerialIncrement ( "001" ; Max ( シリアル初期化_自己リレ::シリアル ))

のように自己リレをして計算式でシリアルを生成する場合なのですが、私のお客様の会社で恐れていたことが何度か発生してしまいました。

クラウドサーバー仕様・10拠点のPOSシステムで、番号の衝突が起こってしまったのです。普通は、頻繁に起こる事は無いのですが、POSを使用するということは現金商売なので常に各拠点でレコードが動くわけです。Max値というのがくせ者で、自己リレだろうがMax値を探す（データをなめる）時間というものが発生し、拠点間でお互いに衝突をしてしまうのです。

当然、計算が変わってきてしまうので、丁重にお詫びして、修正し

この計算は表面上は残し、裏ではフィールドオプションのデフォルトのシリアルに変更しました。（僕はUUIDが嫌いなので・・・笑）

それからは衝突も無く、ちゃぁーんと動いています。

んで、本題の

FileMakerの集計は遅くないよ！

うちのお客さんのところは200万明細超えてもサクサク動いてます。

納品するシステムは商品ですから、ここに紹介するような内容とは、ちょっと違いますが・・・(笑)

重いという方、多分ですが、集計させる側のテーブルのフィールドの計算式が多過ぎなのではないでしょうか。

単純な単価×数量＝金額程度でも５万明細を超えてくると、重くはなりますよ。

どうやったってCase分、Let関数やら再起処理なんか入ってくると、そりゃ集計なんかは明らかに遅くなります。これはFileMakerとか、そういう問題ではないです。

極力、集計する側のフィールドは計算式を止め、空の数字フィールドにスクリプトを使用して計算させるか、

見積、売上、請求なんかでも、そのままのテーブルで集計しないで、更新処理で計算式ゼロの別テーブルにデータ転送させ、そのテキストや数字フィールドだけ集まったテーブル側で集計すれば、相当早くなります。（必要の無い索引も外しましょう！）

特にExecuteSQLを使用しての集計は極端に処理が早く感じます。

繰返しフィールドを使用したクロス集計なんかも、違いは実感できます。

（別に分離開発を奨めているわけでもないです）

更新処理という単語が嫌いなお客様もいるので、集計処理とか、とにかく設計段階でいろいろ考えた方がいいかもです。

検索にしてもフィールドに索引が多過ぎると遅くなります。

アプリとデータを分けるファイルの分離というより、

お客様の運用上、見積や売上などのフロント側はいっぱい計算させて、請求時や、集計は計算式の無いデータで行うのが良いのかと思います。（ファイルは分けていますが、一般的に言われている分離とは違うかもです）

前月、前回の締に戻って修正出来るようにすると、自由度は高くなりますが、違うところで歪みが発生します。赤黒処理で対応するなど昔からの方法も悪くはありません。

FileMakerは複数人で開発するようには作られていないので、

あらかじめ、プレハブ建築の様に、各テーブル内フィールドの仕様、それにまつわるスクリプトなどSet化して、依頼によって組合せ調整して開発しています。

出来上がったシステムに更新処理を追加するのは正直しんどいのですが、最初からSetで用意しておけば、さほど開発には時間はかかりません。