みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 (優しく回答しましょう)
You are not logged in.
Pages: 1
お世話になっております。
Filemaker Pro15
windows7,10(端末混在)
社内イントラネットで使用しています。
基幹システムからデータをインポートして、ユーザーが検索したり中身を確認して処理済みチェックをつけたりするような仕組み(処方監査、薬歴管理)を引き続き作成しています。
リレーションを通じた検索条件の一部が異常に遅く、原因が掴めないためご相談に参りました。
基幹システムから取り込むデータのフィールドは以下のようになっており、同名のフィールド同士で=リレーションします。
テーブルA:伝票番号 伝票作成日 診療科 伝票情報
テーブルB:伝票番号 伝票作成日 診療科 処方日 Rp番号
テーブルC:処方日 Rp番号 Rp内番号 更新番号 患者コード 薬品コード 処方量など
リレーション:テーブルA−テーブルB−テーブルC
A:B、B:Cはそれぞれ1:多
これに、患者テーブル::患者コードや、薬品テーブル::薬品コードなど他テーブルと=リレーションを組んでいます。
そこに、監査状況を記録するテーブルを新設し、
テーブルD:処方日 Rp番号 Rp内番号 更新番号 監査状況コード 担当者コード 監査日時
としてテーブルCと=リレーションさせました。
以上の条件でテーブルCの表示用レイアウトから検索する場合、「監査状況コード」(テキストデータ)をキーにして(コード=1で)検索をするととても遅く、8万件から2件探すのに数十秒かかってしまいます。(ほかの条件もあるのですが、この条件を削除するとほぼ一瞬で抽出できます)
計算は使っておらず、フィールドはタイプを揃えてすべて索引作成設定にしています。ファイルが別ファイルですが他のマスタも別ファイルのものはありますし、なぜこれだけが遅いのか、また解決策はあるのか、ご教示いただけましたら幸いです。どうぞよろしくお願いいたします。
Last edited by masaki (2021-04-27 11:53:32)
Offline
「監査状況コード」はどのテーブルにあるのでしょうか?
検索結果の数ではなく検索対象のレコードの数(リレーション越しならばリレーションを通した全レコード)でパフォーマンスが変わります。
非保存の計算フィールドはパフォーマンスへの影響を配慮されることが多いのですが、
別のテーブルのフィールドをリレーション越しに検索する場合も同様に配慮が必要です。
どうしても必要ならば「監査状況コード」を除いた条件で検索したのち「監査状況コード」で[対象レコードの絞り込み]を行うと良いかも知れません。
Offline
ありがとうございます。
「監査状況コード」はどのテーブルにあるのでしょうか?
テーブルDにあり、テーブルCとリレーションしています。(説明記載に誤りがあったので直しました。すみません)
非保存の計算フィールドはパフォーマンスへの影響を配慮されることが多いのですが、
別のテーブルのフィールドをリレーション越しに検索する場合も同様に配慮が必要です。どうしても必要ならば「監査状況コード」を除いた条件で検索したのち「監査状況コード」で[対象レコードの絞り込み]を行うと良いかも知れません。
ご指摘の通り、他条件で検索後に絞り込みをしても、変わらず異常に時間かかってしまうのです。テーブル内にデータを同梱させることも考えたのですが、Cが更新毎に新規レコードとなるので、更新前後のデータと関連付けるには別テーブルの方が使い勝手が良さそうなのでなんとかできるならなんとかしたいのです。
リレーション条件数の多寡は影響するものでしょうか?
Last edited by masaki (2021-04-27 12:08:46)
Offline
他条件で検索後に絞り込みをしても、変わらず異常に時間かかってしまうのです。
索引が破損していませんかね?
テーブルDで検索した場合はどうなりますか?
データベース定義で[索引設定済]となっていると思いますが、
「なし」に変更して[必要時に索引を自動設定]もオフにしてデータベース定義を終了します。
この操作で索引が無くなるので、もとの設定に戻して検索を行えば索引が再作成されます。
追記)リレーション条件はパフォーマンスに影響します。
複数のフィールドでリレーションを作るより可能であれば複合キーを生成したほうが良いこともあります。
Last edited by Moz (2021-04-27 12:23:01)
Offline
テーブルDで検索すると速いです。
監査状況コードフィールドの索引を再作成してみましたが変わりませんでした。
リレーションの、複合キーへの変更を試してみます。
リレーションに用いている他のフィールドも索引の再作成をしてみたほうがよいでしょうか。
Offline
横から・・
テーブルの構成、リレーション等
ほとんど分からないことだらけですが、、
> テーブルCの表示用レイアウトから検索する場合、
> 「監査状況コード」(テキストデータ)をキーにして(コード=1で)検索
これは、
テーブルCのレイアウトにある、
テーブルD::監査状況コード
フィールドを検索する。
ということでしょうか?
> Cが更新毎に新規レコードとなるの
更新前のレコードはそのまま有るんでしょうか?
Offline
リレーション先にあるフィールドの検索は、遅くなります。8万レコードだとその程度は汁分ありえますね。
テーブルDで検索して、関連レコードへ移動 でテーブルC を表示させるのがいいのでは。
ただ、テーブルCD はほぼ同じデータを持っているようなので、統合してしまうのが将来的には有理かと思います。
Offline
単純に対象となるレコードが多いのか......
リレーションに用いている他のフィールドも索引の再作成をしてみたほうがよいでしょうか。
索引の破損ではないようなので不要でしょう。
Shinさんの書かれている逆転の発想が良いかと。
→ テーブルDで検索した対象レコードに関連するテーブルCのレコードから絞り込む。
Offline
> Cが更新毎に新規レコードとなる
ということは、更新されれば新たに監査対象になるのでは。
> 更新前後のデータと関連付ける
が目的ならば、処方日 Rp番号 Rp内番号 で自己リレーションを貼れば、更新履歴が一覧できます。
Offline
「同名のフィールド同士で=リレーション」
#4Mozさんのの言い換えになりますけど、現状は「主キー」がない(主キーが単一フィールドでない)状態なので遅くなってる気がします。
Moz様、himadanee様
リレーションキーを1つにしたらとても速くなりました。
ひとまずこれでやってみようと思います。
ありがとうございました!!
チポ様
横からありがとうございます。
>テーブルCのレイアウトにある、
>テーブルD::監査状況コード
>フィールドを検索する。
>ということでしょうか?
テーブルCのレイアウトで、検索実行スクリプトから検索する、です。フィールドは置かなくても検索できると聞いたのでやってみました。
> Cが更新毎に新規レコードとなるの
>更新前のレコードはそのまま有るんでしょうか?
リレーションキーすべてを維持したレコードという意味ではそのままありますが、中身は削除された旨の表記に書き換わります。
Shin様
遅くなってしまうものなのですね……。
ありがとうございます。
関連テーブルへ移動するには一度テーブルDのレイアウトに行ってそこから、という手順になりますか? (レイアウトを作っていないものでちょっと気になりました)
>> Cが更新毎に新規レコードとなる
>ということは、更新されれば新たに監査対象になるのでは。
そのとおりです。テーブルDのレコードも新しく作ります。…無理に変更前のと繋ぐ必要はなさそうですね。
この先挙動見て、テーブルの統合も検討してみます。
Offline
Pages: 1
[ Generated in 0.007 seconds, 9 queries executed - Memory usage: 545.69 KiB (Peak: 566.23 KiB) ]