みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
いつもお世話になっております。
すみません、また基本的な事なのですが・・・
100万行程の売上データ（数年分）について、
月ごとの売上を見ようと、「販売日時」（例：20170101）の、左から6文字を抽出した「販売年月」（例：201701）を作成する為に、
新しいフィールド「販売年月」を作り、その内容を「Left ( 販売日時 ; 6 )」で全置換しようとしました。
ところが、この処理が延々と15分程かかるのです。
Accessでは似たような処理で１分もかかったことがありません。
たかだか置換でこれほど時間がかかる物なのでしょうか。
それとも、そもそも自分のデータから、似たデータを複製しようとする処理そのものを改めるべきなのでしょうか。。。
よろしくお願いいたします。
Offline
> 100万行
行って何？ 100万レコードのこと？？
FMが15倍も遅いって？本当に確証されているのなら、Accessを使われては！！
計算フィールドでなく、計算値の全置換を使う理由は？
Offline
Hiro様
ご返信ありがとうございます。
100万レコードの事です。
私もそうしたいのは山々なのですが、どこの世界にも信者の様な方はいて、今回の案件はFM一色なのです。。。
計算フィールドでない理由は、そのフィールドがリレーション先である為です。
ただ、私も「リレーション先が計算フィールドだと動作しない」という思い込みを信じているだけなので、もう少し試してみます。
Offline
100万レコードのLeft関数での全置換で、そんなに時間かからないですよ。CPU:i5のPCで、単体利用で40秒くらい、共有でも2分以内でした。
共有の場合は、ネットワーク状況に左右されるかも。
あと、集計を取るために、201704 などの新たなフィールドを作らなくても、検索するとか、リレーションを張る事で集計した方が良いかと思います。
>（例：20170101）
コレは、テキストになっているのでしょうか？日付は、日付として扱った方が、素直に処理出来ますよ。
以下のような検索指定も出来ますし、表示形式を変えるのもカンタンです。
http://www.filemaker.com/help/15/fmp/ja … es.html%23
2017/04/*
2014/7/{1...15}
2015/{1..3}/{10..16}
Offline
> 計算フィールドでない理由は、そのフィールドがリレーション先である為です
日付が関連テーブルのフィールドということですか？
現テーブルから見たレコード数の関係が、
多対1
ならば、
関連テーブルで処理した方が早いでしょう。
これを計算フィールドしても何ら問題ないですよ。
小計パートを使った集計だと、
年月フィールドが必要ですが、、
年月ごとを1レコードとする別テーブルで集計した方がいいかも。。
現テーブルを関連テーブルとするには索引保存した日付フィールドが必要になりますが。
Offline
同じテーブル内のフィールドのみを参照するので、計算フィールドにしても索引は作れます。計算フィールドにするのがベストでしょう。
または、リレーションの設定を範囲に変えるか、でしょう。
Offline
> 私もそうしたいのは山々なのですが、
・性能差異が15倍もあるなら、何らかの比較テスト上の問題・原因があると考えてみて下さい。
・常識的に考えても、商業ソフトでそんな大差は許されません！
> どこの世界にも信者の様な方はいて、。。。
・FMファンは、信者ではなく、科学技術者です、もちろん ~~;
> 計算フィールドでない理由は、そのフィールドがリレーション先である為です。
・照合先キーはフィールド「索引」が必須なのであって、「計算」フィールドかどうかは関係ありません。
>「Left ( 販売日時 ; 6 )」
・このテキスト演算式の計算結果が意図した結果(yyyymm)になる保証はありますか？
・FMの日付書式に(yyyymmdd)形式はありません。
・販売日時はテキスト値(yyyymmdd)であることが担保されていますか？
Last edited by Hiro (2017-04-14 12:58:17)
Offline
＜qb_dp様＞
ご返信ありがとうございます。
わざわざ時間まで調べて下さりありがとうございます。
ご指摘通り、横着せずスクリプトの検索で乗り切ります。
日付も個人的に苦手で数字での処理を行っておりましたが、日付でやってみます。
ありがとうございました。
＜チポ様＞
ご返信ありがとうございます。
現テーブルから見たレコード数の関係は１対多になります。
その関係性によって、どちらのテーブルで計算フィールドを持つか考えればいいのは目からウロコでした。
もうスクリプトの検索で逃げようと思うので、置換は行いませんが、ご指摘ありがとうございます。
＜Shin様＞
リレーションの設定を範囲に変える・・・との事ですが、例えば、
●テーブルAの「販売日時」フィールドに、「20170101」
●テーブルBの「期間」フィールドに、「201701」
とあって、やろうと思えば
『「販売日時」の前6文字』と『「期間」全て』でリレーションを組めるという事でしょうか。
是非詳しく聞きたいです。よろしくお願いいたします。
Offline
ファイルの構造について、詳しい情報が必要です。
販売日時は、テキストで入っている様な感じですが？その情報は、他のテーブルを参照しているのですか？ならば、そのリレーション関係は？
文字での比較やリレーションは、比較的遅くなります。それを日付や数値に変更した方が格段に早くなるでしょう。
Offline
＜Shin様＞
ご指導すみません。
「販売日時」フィールドは、テキスト形式で「20170101」の様な形で入っております。
この情報はどこかを他のテーブル参照しているわけではありません。
販売データ系は全て、元の基幹システムのテーブルデータを参照しておりますので、形式を変えるのは少しためらわれます。。。
Offline
＜qb_dp様＞
もしまだ見て頂ければ幸いと思い書き込ませていただきます。
また初歩的な事で申し訳ないのですが、
「リレーション」ではなく「検索」で、売上テーブルから、売上を集計をしたい対象レコードを絞り込んだのですが、その売上を集計する事が難しいのです。
「リレーション」で対象レコードを絞り込んでいれば、「売上」フィールドをSum関数で指定する事でいくらでも計算できそうなのですが、
「検索」で対象レコードを絞り込むと、絞り込みはあくまで見た目だけなので、いざレコードを跨いで売上を集計しようとすると方法が思いつかないのです。。。
今回、売上テーブルは、会社の基幹システムのテーブルですのでなかなか手を付けづらく、集計フィールドを付ける事も躊躇われます。
検索で絞り込んだデータを関数で集計する事は可能でしょうか。
もしくは基幹データを「ODBCデータソースの追加」で閲覧しているのですが、集計フィールドの追加などは行っても別の場所で支障など出ないでしょうか。
よろしくお願いいたします。
Offline
ローカルで、その部分だけサンプルファイルを作ってみてはどうですか？
フィールドの作り方であるのか、リレーションの組み方であるのか、集計の手順であるのか、ネットワーク速度であるのか、基幹データの参照によるものか、どれが原因かはっきりしていない状態に思えます。
手順は、基幹データをODBCでデータを取得して、リレーション先のフィールドを、全置換を行っている。ということで、よろしいでしょうか？
とりあえず、時間がかかるかどうかだけであれば
フィールドを1個だけもつテーブルを作ります。
スクリプト1で「100万レコード作成」
変数[$Count；1]
変数[$CountMax；1000000]
Loop
新規レコード作成
フィールド設定[フィールド；”2017/04/21” ]
変数[$Count；$Count+1]
ExitLoopIf[$Count>$CountMax]
EndLoop
カスタムダイアログ「終了しました」
これで、レコードを用意します。フィールド内容は、上記は固定してますが、すべてバラバラでも問題ありません。
全置換
Substitute（フィールド；"/"；””）
これで、何秒かかるか確認すれば、置換が問題であるかはわかると思います。これで遅くなければ、それ以外ですから、順々に確認していけば問題点がどこかわかると思います。
また、サンプルファイル（レコード無し）は掲載すれば、皆さんに確認してもらえるかも。
Offline
日付がその形のテキストでも、比較リレーションは可能ですが。テキストの比較になるので、比較的遅くなります。グローバルフィールドに上限値と下限値を持たせて、リレーション条件を比較にすれば良いです。
Offline
Pages: 1
[ Generated in 0.006 seconds, 9 queries executed - Memory usage: 595.05 KiB (Peak: 611.95 KiB) ]