みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
お世話になっております。
下記、少し長いのですがご質問させて下さい。
【現在の状態】
・顧客情報テーブル
がデータベースに存在し、そのテーブル上に
・顧客ID：AAA0001、AAA0002、・・・（各レコード（＝顧客）に固有）
・サービス利用開始日：20170101、 （各レコード（＝顧客）毎に手動で決める）
・その他の顧客情報
が存在します。
このデータを利用して、
サービスの登録用のCSV（以下、登録CSVといいます。）を吐き出す予定です。
登録CSVは別システムに手動でアップロードし、その別システムから登録結果CSVが吐き出されます。
登録結果CSVにはサービスの顧客毎のID・PASSが記載されています。
登録CSVの内容：
・顧客ID
・サービス利用開始日
・固定の設定項目が約20項目ほど。顧客それぞれによらず、「0」や「1」の表記で固定
登録結果CSVの内容：
・登録CSVで登録した顧客ID
・登録CSVで登録したサービス利用開始日
・登録CSVで登録した固定の設定項目が約20項目ほど。
・顧客毎のIDやPASSの項目
となっています。
【問題としていること】
このような場合、これまでのFileMakerの作成では、
登録CSVに必要な固定の設定項目は顧客情報テーブルに作成し、
登録結果CSVを、「登録結果テーブル」にインポートしていました。
（顧客情報テーブル上のフィールド例）
1：顧客IDフィールド（AAA0001）
2：サービスの利用開始日フィールド（201701）
3：固定設定項目フィールド1（＝1 計算フィールドで指定）
4：固定設定項目フィールド2（＝0 計算フィールドで指定）
・
・
・
・
25：固定設定項目フィールド23（＝1 計算フィールドで指定）
等という形でフィールドを作成し、それをエクスポートして登録結果CSVとするイメージです。
これまではサービスの種類が少ないため、上記で問題ないかと考えていたのですが、多種のサービスを申し込む事例が増えそうなため、
下記のことを懸念しています。
・顧客情報テーブルに存在する顧客の全てがそれぞれのサービスを利用するわけではないのに、不要な顧客にまでそれぞれのサービスの申込のための計算フィールドを作ることで動作が遅くなるのではないか
・顧客情報テーブルに大量のフィールドを作ることになるので、動作が遅くなるなど、問題がでるのではないか。
・顧客情報テーブルに大量のフィールドを作ると、見栄えが悪い＆視認性がよくない
【検討していること】
上記を踏まえ、下記の機能を持ったボタン（スクリプト）を作ろうかと思っています。
・ボタンを押すと、
・顧客情報テーブルと顧客IDでリレーションが張られている「サービス申し込みテーブル」（又は、登録結果テーブルとこのサービス申し込みテーブルは共通）に新しくレコードが作成され、
・そのレコードにボタンを押したときに表示されていたレコード上の顧客IDが入力される
・同じユーザーを複数作成しないようにはスクリプト側で制御する
・その後、手動でサービス申し込みテーブルから登録CSVをエクスポートする。
これであれば、顧客情報テーブル側にフィールドを作成しなくてすむかと考えております。
【上記の運用の問題点として考えていること】
・そもそも、ここまでして顧客情報テーブルにフィールドを作成しないようにする必要があるのか。
・新しくサービスを申し込もうとするユーザー一人一人にそれぞれ手動でボタンを押さないといけなくなるため、押し忘れや押し間違いが起きそうである。
以上の状況で、どちらの形で設計および運用するのが良いのか、
アドバイスを頂けませんでしょうか。
Offline
関連付けられているテーブルのフィールドも同時にエクスポートできます。ですから、そのような処理は不要では。
ついでに、懸念事項の
・顧客情報テーブルに存在する顧客の全てがそれぞれのサービスを利用するわけではないのに、不要な顧客にまでそれぞれのサービスの申込のための計算フィールドを作ることで動作が遅くなるのではないか
・顧客情報テーブルに大量のフィールドを作ることになるので、動作が遅くなるなど、問題がでるのではないか。
そのフィールドに索引を作らないのでしたら、関係無いでしょう。そのフィールドを表示したレイアウトを表示する時に、少し遅くなりますが、微々たる物です。
・顧客情報テーブルに大量のフィールドを作ると、見栄えが悪い＆視認性がよくない
見栄えは関係ないかな。管理上等の視認性は悪くなりますので、適当に他のテーブルに振っていく事をお勧めします。
Offline
> ・顧客情報テーブルに存在する顧客の全てがそれぞれのサービスを利用するわけではないのに、
> 不要な顧客にまでそれぞれのサービスの申込のための計算フィールドを作ることで動作が遅くなるのではないか
特に遅くなるようなことはないでしょう。
> ・顧客情報テーブルに大量のフィールドを作ることになるので、動作が遅くなるなど、問題がでるのではないか。
これも特に問題ないと思いますよ
>・顧客情報テーブルに大量のフィールドを作ると、見栄えが悪い＆視認性がよくない
全てのフィールドをレイアウトに置く必要は有りません。
レイアウトに無いから問いってそのフィールドのデータが消える訳では有りません。
レイアウトにはそこに必要なフィールドだけを配置すればいいですね。
上記をふまえても、、
テーブルで共通の、唯一の値を持つフィールドは、グローバル格納にすればいいです。
エクスポートの最、グローバルフィールドは全てのレコードについてエクスポートされます。
Offline
関連付けられているテーブルのフィールドも同時にエクスポートできます。ですから、そのような処理は不要では。
ついでに、懸念事項の
・顧客情報テーブルに存在する顧客の全てがそれぞれのサービスを利用するわけではないのに、不要な顧客にまでそれぞれのサービスの申込のための計算フィールドを作ることで動作が遅くなるのではないか
・顧客情報テーブルに大量のフィールドを作ることになるので、動作が遅くなるなど、問題がでるのではないか。
そのフィールドに索引を作らないのでしたら、関係無いでしょう。そのフィールドを表示したレイアウトを表示する時に、少し遅くなりますが、微々たる物です。・顧客情報テーブルに大量のフィールドを作ると、見栄えが悪い＆視認性がよくない
見栄えは関係ないかな。管理上等の視認性は悪くなりますので、適当に他のテーブルに振っていく事をお勧めします。
Shin様
返信ありがとうございます。
初歩的な質問で申し訳ないのですが、
索引を設定する方が、動作が早くなるかと思っていました。
非保存では”ない”計算フィールドに対して、索引を設定しない方が動作が早いのでしょうか。
>>見栄えは関係ないかな。管理上等の視認性は悪くなりますので、適当に他のテーブルに振っていく事をお勧めします。
別のテーブルにグローバルフィールド作ることで解消致しました。ありがとうございます。
Offline
> ・顧客情報テーブルに存在する顧客の全てがそれぞれのサービスを利用するわけではないのに、
> 不要な顧客にまでそれぞれのサービスの申込のための計算フィールドを作ることで動作が遅くなるのではないか
特に遅くなるようなことはないでしょう。> ・顧客情報テーブルに大量のフィールドを作ることになるので、動作が遅くなるなど、問題がでるのではないか。
これも特に問題ないと思いますよ>・顧客情報テーブルに大量のフィールドを作ると、見栄えが悪い＆視認性がよくない
全てのフィールドをレイアウトに置く必要は有りません。
レイアウトに無いから問いってそのフィールドのデータが消える訳では有りません。レイアウトにはそこに必要なフィールドだけを配置すればいいですね。
上記をふまえても、、
テーブルで共通の、唯一の値を持つフィールドは、グローバル格納にすればいいです。エクスポートの最、グローバルフィールドは全てのレコードについてエクスポートされます。
チポ様
ご返信ありがとうございます。
>>全てのフィールドをレイアウトに置く必要は有りません。
すいません、管理において、テーブルに存在するフィールドの数があまりに多いのが、データベースの管理の画面上で不格好かな、と考えていました。
ちなみに、あるレイアウトに、テーブル上には存在する非保存の計算フィールドを配置していない場合、
各レコードを表示するのは非保存ではない計算フィールドがそのテーブル上に存在する場合と比べて動作は遅くなりますでしょうか。
>>テーブルで共通の、唯一の値を持つフィールドは、グローバル格納にすればいいです。
>>エクスポートの最、グローバルフィールドは全てのレコードについてエクスポートされます。
ありがとうございます、初めてグローバルフィールドというものを確認しました。
リレーションを張っているが無いリレーションのキーとなる値がないテーブルの相手方から値を持ってくることに難渋していて今回の質問になったのですが、
グローバルフィールドで解決しました。
ありがとうございます。
Offline
索引を設定する方が、動作が早くなるかと思っていました。
非保存では”ない”計算フィールドに対して、索引を設定しない方が動作が早いのでしょうか。
索引を作る必要性は，ソートのキーとなる時に，リレーションの関連付けられた先のキーとなる時，検索を行なう時，等です。リレーションのキーとなるフィールドは索引が必須ですが，ソートや検索を行なう時には，索引を持っていないフィールドでも自動的に索引が一時的に作られ処理されます。
それを理解されれば，索引を持たせておく必要性がないフィールドの判断ができると思います。
Offline
[ Generated in 0.006 seconds, 9 queries executed - Memory usage: 589.52 KiB (Peak: 606.06 KiB) ]