初心者のFileMaker pro Q&A (旧掲示板)

ozie

Guest

テーブルオカレンスを分けると、リレーションシップ画面が重複して見づらくないですか？

教本などでは、リレーションを見やすく開発しやすくするために
積極的にテーブルオカレンスを分けるように書かれています。
それぞれが独立したものであれば問題は少ないのですが
そうではない場合も多く、リレーションシップ画面上のテーブルが重複していき見づらくなってしまいます。
リレーションのテーブル選択時の見やすさを優先するか、（テーブルオカレンスを分ける）
リレーションシップ画面の見やすさを優先するか （テーブルオカレンスを分けない）
どちらがいいのでしょうか？

たとえばA-B-Cとリレーションしているテーブルがあって
DテーブルにもAテーブルのデータが必要なのでD-A'と新たにテーブルオカレンスを作成したとします。

あとから、Cテーブルにあるフィールド1個だけをDテーブルのレイアウトに表示させたいとなると
D-A'-B'-C'というリレーションにする必要があり
それなら最初からD-A-B-Cだけにしておけば・・・と思ってしまいます。

ただそうなると関連テーブル選択のリストが異常に長くなって・・・

hogehoge

Guest

Re: テーブルオカレンスを分けると、リレーションシップ画面が重複して見づらくないですか？

レイアウト上に配置したいフィールドが多いほど、TOGが大きくなっていくのは宿命です。
TOGが大きくならないように気をつけて作成することも大切ですが、
その方法がわからない場合、リレーションを作って表示することは決して間違っていないと思います。
今回のケースではDレイアウトでCのデータが必要になったら、D-A-B-C とすればいいのです。

おそらく教本等では「無意味に」大きなTOGを作らないほうがいいよ、レイアウトに関係ないTOがあるTOGというのはダメだよ、と書いてあるのではないでしょうか。

以下のルールにすれば教本通りになるような気がします。

・ 1レイアウト1TOGといったルールを自分の中で作れば、意外と小さなTOGで済む。( アンカーブイモデル等で調べる )
・ 命名規則を決める ( 選択時に探しやすく見やすくなるように )
・ レイアウトからフィールドを取り除いた時など必要なくなったTOはその都度削除するか吟味する ( No more ゴミTO )

Moz

Member

Re: テーブルオカレンスを分けると、リレーションシップ画面が重複して見づらくないですか？

TOG を分ける最大のメリットはカスタムAppのパフォーマンスです。
数十万レコード程度にも満たないカスタムAppでレコード数に比例して動作が重くなる場合
リレーションに問題があるといっても過言ではありません。

リレーションシップグラフが見づらいというのは
・TO がとっ散らかっている
→整列ツールやテキストノート・色分けで整理整頓する
・同じ名前の TO （例：A, A2 ,A' など）があって構造が分かりづらい
→命名規則に問題があるので規則を作り、守る

などが考えられます。
名前の重複が問題となる場合、命名規則で解決すべきです。
hogehogeさんが書いていらっしゃる Anchor-Buoy や命名規則を学習すると自然と解消されるでしょう。

レイアウトに関連付ける TO は TOG の中でひとつだけ
→D-A-B-C（フォーム）D'-A'-B'-C'（リスト）に分ける必要はありません。同じ視点（機能）は同じ TOG でOKです。
リレーションで右から左への参照をしない（できるけど）

Aに関連付いたレイアウトで A-B-C という TOG を利用している場合に
Dに関連付けたレイアウトが必要になった際に A-B-C に A と D にリレーションを作成して D-A-B-C に変更、
D-A-B-C の TOG のうち、D および A が関連付けられたレイアウトを持つことになるのはダメということです。

これを繰り返していると TO 選択時のリストが長くなりミスによる不具合発生の温床となります。
当然パフォーマンスの低下も引き起こしメリットはほとんど有りません。

TOG を分ける大切さなどは体験しないとわかりづらいことですし、
はじめのうちはとりあえず全部繋がっている状態でも良いと思います。誰でも通る道です。

どこかで Anchor-Buoy や命名規則を習得して徐々に変えていけばいいのではと個人的には思います。
※開発済・開発中のカスタムAppを新しいルールで塗り替えるのは失敗する気がします（汗）我慢です。

大切なのは自分の中での開発ルールを作り、守ることでしゅ。
カスタムApp毎に開発ルールを変えるのはのちの自分に不幸を招きます。