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

みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。

1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 (優しく回答しましょう)

You are not logged in.

Announcement

新しい掲示板は、こちら:https://fm-aid.com/forum/t/filemaker


#1 2020-06-24 11:46:25

lpikesee
Guest

テーブルオカレンスグループを分ける基準は?

TOGを無駄に大きくしたくないのですが、
レイアウトごとにTOGを分けると、同じような機能のスクリプトを新たに作らなければなりません。
TOGを分ける基準はどのようにされていますか?
パフォーマンスへの影響などはどのように判断すれば良いでしょうか?
すでに使用しているTOGを分ける時の効率の良いやり方などあるのでしょうか?

例えばTOが30個あるTOGがありそれを今まで使ってきたとして、
そのうち様々な組み合わせの15個くらいを使うレイアウトを新たに複数作りたいとしたら、
TOGを共用しますか?

たくさん?をつけてしまいましたが、部分的な回答でも結構です。よろしくお願いします。

#2 2020-06-24 13:49:50

Shin
Member

Re: テーブルオカレンスグループを分ける基準は?

テーブルオカレンスグループ という言葉はないのですが、おそらく、アンカーブイ 構造でのグループだと思います。
改めて考えるアンカーブイの操作方法と実践
の2019年のセミナーも参考にされてはいかがでしょう。
どの程度の区切りにしていくかは、規模の大きさと好みです。
スクリプトが重複するのは、例えば全く同じ事を行うのでしたら、新しいウィンドウを出して、レイアウトを変更し、スクリプトを呼び出して処理、終わればウィンドウを閉じる、という処理を行ってもいいかと思います。
もっとも注意が必要なのは、計算フィールドの起点オカレンスが異なることによって、異なる結果を返す可能性がある事でしょう。

Offline

#3 2020-06-24 13:53:09

Moz
Member

Re: テーブルオカレンスグループを分ける基準は?

『FileMaker Training Book 中級編』第5章 リレーションシップ
http://content.filemaker.com/fmb18_reg-ja

こちらを読めば基準が詳細に書かれています。

TOGを分ける基準は「レイアウト毎にTOGを分ける」です。
レイアウト毎といっても例えば顧客一覧・顧客詳細など
同じテーブルオカレンスに基づくレイアウトの表示形式違いはセットで考えます。
TOGでレイアウトを持つTOは1つだけです。
この考え方はアンカーブイモデルと呼ばれ現在のところ最も主流なモデリングでしょう。

必要のないTOまでくっついているとレコード数に比例してパフォーマンスに著しく影響します。
レコード数が数十万程度でもたつくのは大抵このパターンです。
アンカーブイモデルにはTOGの共用という思想がありません。
(例外として Selector Connector がありますがこれはアンカーブイを熟知した上で利用するものですし
現在のバージョンではあえて組み込む必要もない考え方でしょう)

ただし、現在動いているカスタムAppに無理に手を入れると碌なことがないので
新たに追加する機能からルールを適用するなどの割り切りは必要でしょう。

アンカーブイの原型となったのは FileMake 7 時代に書かれた
「Key Concepts in FileMaker 7」でしょう。
この時点で既に TOG(テーブルオカレンスグループ)という概念が存在します。
http://www.alquimia-digital.com/filemak … 20FMP7.pdf

Last edited by Moz (2020-06-24 13:58:21)

Offline

#4 2020-06-26 10:45:06

lpikesee
Guest

Re: テーブルオカレンスグループを分ける基準は?

Shin wrote:

スクリプトが重複するのは、例えば全く同じ事を行うのでしたら、新しいウィンドウを出して、レイアウトを変更し、スクリプトを呼び出して処理、終わればウィンドウを閉じる、という処理を行ってもいいかと思います。

ありがとうございます。この方法は試してみたいと思います。

#5 2020-06-26 11:06:54

lpikesee
Guest

Re: テーブルオカレンスグループを分ける基準は?

Moz wrote:

TOGを分ける基準は「レイアウト毎にTOGを分ける」です。
レイアウト毎といっても例えば顧客一覧・顧客詳細など
同じテーブルオカレンスに基づくレイアウトの表示形式違いはセットで考えます。

ありがとうございます。
「セット」と考えてもいい範囲はどこまでなのかを知りたいです。
同じテーブルの一覧でも、ユーザーによってほしい情報やしたい操作がちがうために、レイアウトをユーザーに合わせて分けて作った方がいい場合、
どのくらいの違いならセットと考えるのか(特に後からレイアウトを追加する場合)、アンカーブイ方式に熟練された方の考え方を知りたいと思っています。

#6 2020-06-26 19:59:59

Moz
Member

Re: テーブルオカレンスグループを分ける基準は?

どこまで分けるかの明確な答えはありません。
具体的にどのようなケースで迷っているのでしょう?

例えば注文の管理を行う目的のカスタムAppを作っているとします。
注文の一覧・注文の詳細のレイアウトが使うTOGは同じです。

注文明細に同じ顧客の過去の注文を表示するレイアウトと表示しないレイアウトを作成し、
ユーザによってどちらからを表示するとします。この場合も同じTOGで良いでしょう。
「注文」をアンカーとして右側に広がっていくTOGです。

同じテーブルをTOとするレイアウトで極端にリレーションが異なる場合はTOGを分けるかも知れませんが
そうでなければ同じTOGで良いと思いますよ。

対してTOGを逆走すれば作れる場合、例えば「注文明細」をTOとした請求書レイアウトが必要なケース。
これは上記の注文のTOGを逆走すれば作成できますがTOGは分けます。
TOGでレイアウトを持つTOはひとつだけです。

もっと厳格なTOGの分け方をしている方もいますがやり過ぎは良くないと個人的には思います。

熟練者の答えが正しいとは限りませんし、ある程度の試行錯誤・トライアンドエラーから得る経験値は必要でしょう。

例えば Selector Connector を熟練者の誰かが今は使わなくてもよいと言ったとします。
熟練者は使ってみて理解した上で現状のバージョンで敢えて使わなくても大丈夫だと判断しています。
これを聞いた初心者が Selector Connector は不要と言ってしまうことには天地ほどの差があります。

Offline

#7 2020-06-27 08:28:03

Shin
Member

Re: テーブルオカレンスグループを分ける基準は?

> 同じテーブルの一覧でも、ユーザーによってほしい情報やしたい操作がちがうために、レイアウトをユーザーに合わせて分けて作った方がいい場合、
元の考え方からいうと、それぞれのレイアウトごとに分けていきますが、例外的に、同じ動きをさせているのでしたら、同じグループを流用するのもありでしょう。
極端な例として、欲しい情報や操作を、バーチャル(フィールドの表現方法やスクリプト内で動作を分岐しているなど)で実現できるのでしたら、1グループでいいですね。

Offline

#8 2020-06-29 09:47:03

lpikesee
Guest

Re: テーブルオカレンスグループを分ける基準は?

お二方ともありがとうございます。とても参考になります。
例外もあるということですね。

アンカーではないTOにレイアウトをもたせることはしていません。
それは社内開発者の中でルールとして守ることにしています。

具体的には製造の工程管理に使っています。
自分の未完了のタスクを検索するにあたり、材料ごとで検索したい部門と、納期時間ごとで検索したい部門などの違いがあるので、
ヘッダーやフッターに配置するボタン、表示する数値をレイアウトごとに変化させています。
使用するリレーションはほぼ同じなので、この場合は同じグループでいきたいと思います。

iOSのユーザーからパフォーマンスをもっとあげられないのか、という要望があります。
リレーションを絞った別グループを作って、パフォーマンスがどのくらい上がるかも試してみたいと思います。

リレーションやスクリプトを組み直す手間と、今後の開発のしやすさ、パフォーマンス向上の効果を見極めながらやっていきたいです。

#9 2020-06-29 12:18:29

Shin
Member

Re: テーブルオカレンスグループを分ける基準は?

おそらく、リレーションの変更ではパフォーマンスは上がりません。一番大きく効くのが、索引の持たせかたです。

Offline

Registered users online in this topic: 0, guests: 1
[Bot] claudebot

Board footer

Powered by FluxBB
Modified by Visman

[ Generated in 0.008 seconds, 9 queries executed - Memory usage: 542.38 KiB (Peak: 563.28 KiB) ]