みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
◆テーブル
見積テーブル
●フィールド構成
ユニークな見積ID
請求テーブルの外部キー
見積日
◆テーブル
見積明細テーブル
●フィールド構成
ユニークな明細ID
明細テーブルの外部キー
作業
金額
◆テーブル
請求テーブル
●フィールド構成
ユニークな請求ID
請求日
※次のケースはあくまで例です
Case1
取引先「この、リスト形式レイアウトの見積一覧に請求日を出してよ。」
自分「了解です」
自分（リスト形式レイアウトに、見積からリレーションをつないだ請求先の請求日フィールドを配置・・・っと）
取引先「一覧のスクロールが遅いよ！」
自分（じゃあ・・・請求日はルックアップフィールドで持つ・・・と）
取引先「請求立てたけど、来月に回すことになったし、請求テーブルの請求日変えたけど見積テーブルに反映されてないけど！？」
自分（リレーション先見せるのも遅いからだめ・・・ルックアップしてもデータは変わらない・・・どうすれば）
Case2
取引先「この作業がこの期間にどれだけの金額を稼いでるかみたいんだけど・・・」
自分「了解です」
自分（見積明細テーブルからリレーション先の見積テーブルを検索して・・・集計っと）
取引先「検索が遅いんだけど！」
自分（関連レコードを検索したら遅いよな・・・ルックアップするか・・・）
取引先「明細追加してから見積日変えても集計に反映されないよ！」
自分（再ルックアップするにしても見積が多すぎる・・・どうすれば・・・）
・・・という感じです。
リレーションしたはいいものの、そのリレーション先のデータをどう表示、取得しようか悩んでいます。
ルックアップでもってくれば、定期的に再ルックアップをかける必要があります。かといって、リレーション先のフィールドをリストレイアウトに配置するとスクロールは遅くなります。
初歩的な質問ですが、皆様はどうされていますでしょうか？ご教授お願いします。
オールマイティの処方はありません。解法はケースバイケースです。
問題の都度、最善の処方を考えるのが開発者の仕事です。
理論的に出来ない事は絶対出来ませんから、「出来る事」を組み合わせて最善を尽くします。
その意味で、出来る事の個人「引き出し」を増やす事が、回答と云えるかも知れません。
（この攻略過程が難題である程、制作者は楽しいものです。）
Offline
オールマイティの処方はありません。解法はケースバイケースです。
問題の都度、最善の処方を考えるのが開発者の仕事です。
理論的に出来ない事は絶対出来ませんから、「出来る事」を組み合わせて最善を尽くします。
その意味で、出来る事の個人「引き出し」を増やす事が、回答と云えるかも知れません。
（この攻略過程が難題である程、制作者は楽しいものです。）
ご返信ありがとうございます。確かにそうですね。
Hiro様なら、Case1、Case2はどう対応されますでしょうか？
Lookupでデータを同テーブルに保持するのか、それともそれ以外で解決するのかと、二択しかないように思えますが…。
より良い方法があるなら知りたい次第、そういった探求心です。
・事例で、関連レコードは遅いと決めつけていますが、それは誤りです。
・理由は、照合キーの索引は必須規定しており、照合処理自体は敏速です。
・遅くなるケースは、関連参照フィールドが非保存の高負荷な処理を要する場合です。
・また、関連データは非索引となるため「関連データの再利用」は遅いです。
・その非保存が問題だとしてその対策の1案は「ルックアップ」ですが、それが全てではありません。
・「結果保存の計算式」も有効です。例えばLookup関数やExecuteSQL関数などで、計算式は自由度が高くより広範に対応可能です。
・例えば、結果保存のLookup計算式でも自動更新ルックアップが組めたりします。
・やはり「出来る事」のポケットを沢山持つことです。
Offline
一応。例示のケースでの解析をしてみると、（架空の話でしょうが）
> 自分（リスト形式レイアウトに、見積からリレーションをつないだ請求先の請求日フィールドを配置・・・っと）
> 取引先「一覧のスクロールが遅いよ！」
簡単な計算でしょうから、1項目適度の関連フィールドの参照では、遅くなることはないでしょうね。各伝票の明細が何万件に及ぶような事例では発生するかもしれませんが。
> 取引先「請求立てたけど、来月に回すことになったし、請求テーブルの請求日変えたけど見積テーブルに反映されてないけど！？」
作り方で、1テーブルに纏めてしまうこともできます。ちょっと独特の構造になってしまいますが、バインダーの中に、見積もりから請求までを挟んであるイメージになります。
> 自分（見積明細テーブルからリレーション先の見積テーブルを検索して・・・集計っと）
> 取引先「検索が遅いんだけど！」
検索キーのあるテーブルで抽出して、関連レコードへ移動することで、同じ動作になります。この場合、見積もりテーブルの日付で抽出して、関連レコードへ移動 で見積もりテーブルへ移動すると、極めて高速です。
> 自分（関連レコードを検索したら遅いよな・・・ルックアップするか・・・）
> 取引先「明細追加してから見積日変えても集計に反映されないよ！」
トリガーでスクリプトを動かしてもいいですし、色々方法はありますよ。
Last edited by Shin (2019-06-29 12:26:05)
Offline
皆様、レスありがとうございます。
レイアウトに設定したオカレンスのテーブル以外のフィールドを置くと、一覧レイアウトではスムーズにスクロールできないと思うのですが…私の検証不足でしょうか？
もちろん、照合キーの索引は”全て”に設定しています。
Hiroさんのおっしゃる、 結果保存のlookup計算式フィールド の自動更新ルックアップ方法が気になっています。ぜひ教えていただけませんか？
Shinさんの対象レコードから関連レコードへ移動は大変参考になります、ありがとうございます。
> レイアウトに設定したオカレンスのテーブル以外のフィールドを置くと、一覧レイアウトではスムーズにスクロールできないと思うのですが…私の検証不足でしょうか？
具体的に見てみないとわかりません。特に、そのフィールドがさらに別のテーブルのフィールドを参照していると、当然遅くなってくるでしょう。
全体の構成やフィールド定義などを書き出していれは。如何でしょう。
Last edited by Shin (2019-07-01 09:25:59)
Offline
皆さん標準的なポータル表示なら遅くなることはない、と言っています。
しかし、貴方の事例では実際遅くなっているのなら、貴方固有の特殊事情があるのでしょう。
その具体的原因究明は、現状、全てを把握し、即時テスト環境の整った貴方以外ありません。
現状、具体構成不聞の部外者がアドバイスできるのは、大まかなアタリくらいで、
考えつくままに、
・ポータル表示フィールドが非保存の高負荷計算？
・リレーション「元」照合キーが非保存の高負荷集計計算値など？
・リレーション「先」テーブルに高負荷なソートオプション設定？
・ポータルに高負荷なソート・オプション設定？
・ポータルに高負荷なポータルフィルター・オプション設定？
などなど、取り合えず、
Offline
テーブル
伝票テーブル
従業員の外部キー（索引設定済み 全て）
従業員
主キー（索引設定済み 全て）
名前（ノーマルなテキストフィールド）
レイアウト
リストレイアウト
伝票テーブル
伝票からリレーションが繋がった従業員の 名前フィールド を配置
これで1000レコード作ってスクロールしてみて下さい。
こちらの環境ではこれだけでスクロールがカクつきます。スペックは十分です。
同じようなテーブル構成で実運用していますが、来店テーブルでのレコード数は10000程度でもスクロールにストレスありません。（顧客名などの基本情報は顧客マスターより取得していますし、複数の購入履歴も、それぞれの明細から直近情報を都度取得しています）
顧客マスターは50000レコード程度ありますが、こちらもストレス無くスクロールできます。
どちらも、表示しているフィールドは、関連テーブルから情報を取ってきているものも多く含まれています。
FIeMaker server で共有し、端末は i5 の普通の iMac です。
Last edited by Shin (2019-07-01 15:16:53)
Offline
そうですか…。何か勘違いをしているんでしょうか…。別テーブルのフィールドをレイアウト上に何も考えず置いて、それでスクロールや動作が快適なら是非ともそうしたいのですが…。
難しい計算値でもなければ索引設定をしていないわけでもない、ただのリレーション先のテキストフィールドを配置するだけでリストのスクロールに影響が出る、のですが…。
どうしても自己解決がつかないのでしたら、その問題のファイルを公開してみればいかがですか。
索引設定が必要なフィールドは、リレーション先のキーになるフィールドです。それ以外は、必要に応じて設定しますが、通常は FM が自動的に判断してくれますので、わざわざ設定しなくてもいいですよ、
Offline
リレーション先のテーブルのフィールドをレイアウト上に配置するとパフォーマンスに影響すると
思われた根拠となる資料はあるのでしょうか？Webページ・書籍等......
散々他の方も書いて下さいっているのでアレですが......
パフォーマンスに影響を及ぼすのは以下のような状態が重複して発生している場合が殆どです。
1つのフィールドを配置して1000レコード程度では問題ないと思われます。
・集計フィールドが配置されたレイアウトで多数のレコードを表示
・非保存の計算フィールドが多数配置されたレイアウトで多数のレコードを表示
・フィールド以外の計算式に非保存の計算フィールドやリレーション先のフィールドを含む計算式が多数ある
（次の場合にオブジェクトを隠す、条件付き書式、タブ名、ボタンバーラベル、ポップアップヘルプ、プレースホルダテキスト等）
#9 によれば1000レコード程度でカクつくということなので書かれている情報を元にファイルを作りました。
http://bit.ly/2NrMVBu
このファイルでもカクつきますか？
また、環境についての情報がないように思えますが、バージョンやお使いのOSなどの情報は公開できませんか？
Last edited by Moz (2019-07-01 16:56:37)
Offline
リレーション先のテーブルのフィールドをレイアウト上に配置するとパフォーマンスに影響すると
思われた根拠となる資料はあるのでしょうか？Webページ・書籍等......散々他の方も書いて下さいっているのでアレですが......
パフォーマンスに影響を及ぼすのは以下のような状態が重複して発生している場合が殆どです。
1つのフィールドを配置して1000レコード程度では問題ないと思われます。・集計フィールドが配置されたレイアウトで多数のレコードを表示
・非保存の計算フィールドが多数配置されたレイアウトで多数のレコードを表示
・フィールド以外の計算式に非保存の計算フィールドやリレーション先のフィールドを含む計算式が多数ある
（次の場合にオブジェクトを隠す、条件付き書式、タブ名、ボタンバーラベル、ポップアップヘルプ、プレースホルダテキスト等）#9 によれば1000レコード程度でカクつくということなので書かれている情報を元にファイルを作りました。
http://bit.ly/2NrMVBu
このファイルでもカクつきますか？また、環境についての情報がないように思えますが、バージョンやお使いのOSなどの情報は公開できませんか？
わざわざ、サンプルファイルをご用意していただきありがとうございます。
ちなみに、何か書籍やで根拠を得たわけではなく、これまで作ってきたシステムが全てそうだったので、経験則です。
いただいたファイルですが、ローカル環境ですと、全くスクロールには問題ありませんが、やはりServerにアップロードすると、スクロールに突っかかるような動作でした。
と、すると、サーバーでしょうか？
環境ですが… FM,FMS 17 FMSはAWSのwindows server EC2 t3.large に乗せて使用しています。PCはMacbook Pro OS:mojave 10.14.5 です。
メールではないので全文引用しなくて大丈夫です。
索引についてなど基礎知識の習得に FileMaker Master Book などの公式書籍を読まれることをおすすめします。
原因究明には知識の積み重ねも大切です。
あのファイルでダメだとするとちょっとでも複雑なファイルならすぐダメになりますね。
t3.largeなら安価ですがそこまでダメでもないのでスペックよりもインフラ面の影響に思います。
AWS までの接続はどのように確保していますか？もちろん日本リージョンですよね。（回線など）
また他の目的で AWS を共用していることはないですか？
そもそもの問題として突っかかるというのはどのような感じでしょう。
体感は個人差もあるので一概に遅いと言い切れないのかも知れません。動画などあればよいのですが。
Offline
Pages: 1
[ Generated in 0.009 seconds, 12 queries executed - Memory usage: 565.41 KiB (Peak: 586.31 KiB) ]