みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
お世話になります。
わりと大規模なシステムをいろいろな方に教えてもらいながら１年以上かけて作っています。
始めはさくさく動いていた入力画面がなんだか反応が遅くなってしまいました。
マスターテーブルと本体のデータベースのファイルは別ファイルにすると読み込み速度（検索速度）が遅くなることはありますか？
具体的にはポータルに入力していくことで明細にレコードが追加されていくしくみです。
ただ、遅くなるのは行が１０行以上になってきたあたりからで、始めの１行～3行くらいは早いままです。
もしマスタをメインのシステムファイルに統合すれば劇的に改善するのであれば頑張ってやってみようかなと思うのですが
できればいまさら変更したくはありません。
ご教授よろしくお願い致します。
Offline
外部のマスターファイル（内容はほぼ固定でインデックス作成済みの物）を参照しても、速度には影響は小さいでしょう。
おそらく、ファイルが大きくなってきて、内部のフラグメントが酷くなってきたのだと思います。一度、ファイルの最適化保存を行ってみてください。
Offline
ありがとうございます。
喜び勇んでやってみたのですが残念ながらあまり改善されませんでした。
ローカルに置いて（サーバーで使うので）やってみましたがこれも違うようです。
私の作っているシステムの特徴として
・同じフィールドを重ねて表示、非表示させたりしている
・計算フィールドのしくみがやや複雑
・マスターのデータは３つ。最大レコード数は１５００くらいなので数的にはたいしたことない
・視認性の為、デザインに凝っている（元をかなりいじっている。設定を別名保存しないとよくないと言われてからはそれをするようにしている）
・非保存にしたくないが、どうしてもそうしないといけない（それ以外できない設定になっているなど）ところがあり、それが悪さしているのかも
と言ったところです。
行をどんどん追加していくと２０行くらいになると動作がもったりして来ます。
計算フィールドやリレーションを組んでいるフィールドが重くなっているような感じです。一覧から選ぶのは全く遅くならないです。
なので、計算フィールドの計算、やリレーションのデータを取って来る作業が重いのかなと言う気がしますが
始めの数行は全く遅くはないのでもしやグラフィックの表示の問題なのかな・・・？などと思っているのですが。
何か分かる事気が付くことは他にありますですでしょうか？
Offline
ソートや検索に、索引なしのフィールドを使っているのでは。
Offline
以前「突然もたつくようになった」というタイトルで投稿させて頂きました。そちらにも書き込ませていただいたのですが
索引なし、が結構あったのですべて、とかにしてみたのですがそれほど変わりませんでした。
考えられることはいろいろやったのですが。。
Offline
横から、
回答できるか分かりませんが、、
「行」
と書かれているのはポータル行のことですか？
グラフィック
とは？
ポータル行にオブジェクトフィールドがある？
Offline
パフォーマンスが低下する原因の例として以下のようなものがあります。
・リレーションシップにアンカーブイを採用していない
→すべてのテーブルオカレンスが繋がっている
→テーブルオカレンスグループ（繋がれたTO群）にレイアウトを持つTOが複数ある
※アンカーブイについては検索してみましょう
・非保存の計算フィールドをレイアウトに多数配置している
・非保存の計算フィールドを参照するレイアウト計算式が多数ある
→条件付き書式・次の場合にオブジェクトを隠す等のこと
・個別のスタイルを持つレイアウトオブジェクトが多い
→名前を付けて保存してもスタイル数が増えればパフォーマンスは落ちる
・集計フィールドが不要時にも表示されている
・レイアウトに高解像度の画像を貼り付けている（デザインとして）
行がポータル行を指すのであれば低下する原因がポータル行に配置されたフィールドや計算式にあるのでは、と。
あと別スレッドで気になったのはマシンによって速度変わっていることですかね。
書かれているようなレコード数では最適化コピーでパフォーマンス改善しても僅少です。
※最適化コピーが何かを読めば必要な状況にあるか否かは分かると思います。
https://fmhelp.filemaker.com/help/16/fm … -copy.html
検索・リレーションには索引が利用されますが、ソートと索引は関係ありません。
編集）読みづらかったので色付けました。スンマセン。
Last edited by Moz (2018-02-01 09:48:00)
Offline
みなさま有難うございます。（Moz様：読みづらかったので色付けました。＞全く問題ありません）
スクリーンショットを貼ろうと思ったのですがやり方がわからず断念しました・・・。
結局、原因がわかりました。ポータルのレコード行にたくさんのフィールドを置いているのですが試しに３フィールドだけ残して他フィールドを削除
（表示から外しただけ）をしてみたら、何行追加してもサクサク動くようになりました。
フィールドの存在自体を削除したわけでは無く、ただポータル行から表示を外しただけなので内部的には計算は動いているのだと思います。
これは描画の問題なのでしょうか。。？とにかく、先にこれをやってみるべきでした。すみません。
全体でだいたい30くらいのフィールドとボタンを置いており、それらにいろいろとスクリプトをトリガなどで仕込んであります。
スタイルは別名保存しましたがなるべく統一して使い回す形にしてあるのでそれほどたくさんではないと思います。
いろいろ仕込んだ物はどれも苦心して組み上げたものばかりで、この機能が無いとせっかくのシステムが便利だと感じなくなる可能性があります。
描画の問題？と上で書きましたがパソコンの性能がかなり低くてもそんなに変わらないので単にグラフィックカードがどうとかそういうことでも
無い気がしますが。
何にせよこれは誰かに診てもらうしかないような気がしてます。
Last edited by mukanta (2018-02-01 11:33:16)
Offline
原因は描画の問題ではないのでグラフィックカードでは解決しないです。
ポータル行に配置しているフィールドのうち、非保存の計算フィールドが原因でしょう。
非保存の計算フィールドは表示する瞬間に計算が行われるので数に比例してパフォーマンスが落ちます。
※配置していなければ再計算されないのでテーブル内には存在していても大丈夫です。
前述と重複しますが非保存のフィールドはフィールドとして配置しているものだけでなく
条件付き書式や［次の場合にオブジェクトを隠す］などのレイアウト計算式の中も含みます。
対策として
・ポータル行に配置しているフィールドのうち不要なものがないか再検討
・条件付き書式などのレイアウト計算式を利用している場合も同様に再検討
・必要なフィールドを非保存ではなく索引付きのフィールドに変えられないか検討
（トリガなどで索引付きフィールドに計算結果を入れる）
といった方法が考えられます。
Last edited by Moz (2018-02-01 11:42:50)
Offline
Moz様
ありがとうございます。
＞条件付き書式や［次の場合にオブジェクトを隠す］などのレイアウト計算式
大量に使っています。。これも遅くなる原因なのですか。。簡単に設定できるものなので多用しています。。
非保存よりかはトリガでスクリプトを使う方が早いのですね。
なんにせよ、困りました・・。この場合はフィールドが赤になる、とかで視覚的にはっきりわかるようにし、この時にはここをいじって欲しくないから消えておくようにしたりとか、
どれもこれも大事なのですが。これらの設定は勉強始めたばかりの頃にこの機能を見つけて簡単なのでそれベースでシステム構築を始めたものですから
それを何か他のやり方で置き換えるとなると、かなりベースから見直さなくてはいけなくなるかもしれません。
Offline
今Moz様の言う通り見直しています。ボタンの条件書式スクリプトを外したり・・。
結果、劇的に早くなってきています！！！
う～ん、、結局、「何かを犠牲にしなければいけない」という結論に達しましたが、
確かに、私自身がシステム開発を始めたばかりであり、「詰め込み過ぎ」「やりたいこと全部突っ込む」といったやり方で
システムに無駄な圧力がかかっていたのかもしれません。反省します。
実際使ってみたらそこまで便利（風）にしなくても、それは使用者にゆだねてもいい部分かもしれない、や、
そこまで便利にしようとし過ぎるあまり、かえって操作が猥雑になり、内部処理的にも問題が出てきていたのかもしれません。
すごくいい勉強になりました。
ちょっと、捨てるところ、簡潔にできるところ、いろいろやってみます。世の中に完璧はない。完璧を目指すあまり逆に使いにくくなる。と言う教訓を得た気がします。
そういうところを経験で学んでいくのが大事なのかな、一番むしろ難しいところ、なのかな。と思いました。
ありがとうございました。
追記：まとめておくと、表示非表示（次の場合にオブジェクトを隠す）やフィールドの見た目を変える（条件付き書式）をフィールドに埋め込みまくるとそれらをすべて毎回計算しまくるので
結果、入力作業がもったりしてくることがある。その場合、それらを減らす努力をして簡潔にするよう努める。
Offline
お役に立てたようでなによりです。
「非保存の計算フィールド」が絡むとパフォーマンスを低下させるのであって
［条件付き書式］［次の場合にオブジェクトを隠す］自体はとても便利な機能です。
パフォーマンスへの影響を減らす計算式の書き方もあります。
例えば「非保存フィールド」というフィールドを用いた計算式
Case ( 非保存フィールド = 10 ; 結果01 ; 非保存フィールド = 9 ; 結果02 ; 非保存フィールド = 8 ; 結果03.........etc )このように何度も参照するとそのたびにフィールドの値が計算されてしまいますが、
Let 関数を利用して変数に代入すれば計算は1回だけに減らすことができます。
Let ( [
~変数 = 非保存フィールド
] ;
Case (
~変数 = 10 ; 結果01 ;
~変数 = 9 ; 結果02 ;
~変数 = 8 ; 結果03...etc
) // Case
) // LetLet 関数
https://fmhelp.filemaker.com/help/16/fm … 2Flet.html
Last edited by Moz (2018-02-01 14:49:32)
Offline
[ Generated in 0.018 seconds, 9 queries executed - Memory usage: 562.09 KiB (Peak: 583 KiB) ]