みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
いつもお世話になっております。
最近FMサーバーを導入する運びとなりまして、
便利と思う反面分からないことが急に増えて戸惑っております。
相談内容ですが、外部システムからcsvでデータを取り込み、FMへとインポート・加工を行った運転日報テーブルがあります。
例）
N0 日付 車番 発地 着地 開始 終了 作業 時間 実作業時間
1 11/21 1234 A社 B社 10:00 12:00 走行 2:00 -
2 11/21 1234 C市 C市 11:00 11:30 休憩 0:30 -
ここから特定ルートごとにかかる時間や、○月○日の車番○○の日報などを検索できるようにしています。
そこで「時間」から休憩などの分の時間を引いた「実作業時間」（例では1:30）が必要になるので、
日付＝日付
車番＝車番
開始<=開始
終了>=終了
計算F＿休憩＝作業
No≠No
このような自己リレーションをかけたテーブルを参照した計算式、
運転作業日報::時間 - Sum(運転作業日報＿休憩::時間)
で割り出していました。
これを最初は時刻フィールドにして計算値自動入力＋既存値置き換えにしていたのですがインポート時の計算では正しい結果が出ず、
やむなくインポート後の全置換を行っているのですが、
この全置換に月間で3000～4000件のレコードに対して3～40分もかかってしまいます。
（実際には同じようなリレーション、計算の置換がもう一つあって二回の処理での時間です）
調べていてFMサーバーでは深い場所の計算はさせない方がいいという記事を見たことはあるのですが、
しかしそれほど深い位置の計算にも思えず･･･
何とかして処理速度の向上を図れないものでしょうか？
環境はwin8.1 fmp14 fms13です、よろしくお願いします。
計算フィールドにしてみたらいかがでしょうか？
また、
リレーションが複雑ですから、
日付＝日付
and
車番＝車番
だけにして、
「走行」なら + の時間
「休憩」なら - の時間
になるような計算フィールドの合計で求めたらいかがでしょう。
集計レイアウトでこの計算フィールドの集計
でもいいかもしれませんね。
これなら集計結果だけのリストが簡単に作れます。
Offline
チポ様、素早い回答ありがとうございます。
計算フィールドにしてみたらいかがでしょうか？
計算値自動入力でやる前はその方が処理が早そうだと思って計算フィールドにしていました。
インポートもそれほど時間がかからずそこは良かったんですが、
検索時に少し時間がかかり、（作りが悪いのもあるのでしょうが）特にサーバー導入後は極端に遅くなってしまいました。
そこで計算フィールドをやめたところそれがすぐに済むようになって喜んだのも束の間･･･、で現在に至るというような。
日付＝日付
and
車番＝車番
だけにして、「走行」なら + の時間
「休憩」なら - の時間
になるような計算フィールドの合計で求めたらいかがでしょう。
これなら全置換不要で自動入力だけで対応できそうですね。
良いアイディアなんですが、欲しい情報の最小単位が日ごとでなくルートごとなのです。
本社→A社→B社→本社 という一日の流れを、
本社→A社、A社→B社、B社→本社 のようにバラバラにして各ルートごとに走行などの時間がどれくらいかかったか？を見たいのです。
休憩のレコードでは「どこで」休んだかは分かるのですが、それが「どこからどこへのルート」上なのか分からないので、
開始と終了時間から見てどのルート上での休憩なのかを判断している形になっています。
csvから加工の段階で休憩のレコードにも発地と着地のデータを持たせることができれば、
チポ様のものに「＝発地、着地」のリレーションを加えれば応用ができそうですが、ちょっと大変そうですね･･･
質問からは、実働作業時間は
「走行」
のレコードだけで求めている様ですが、
それが正しければ、
「走行」のレコードだけを対象レコードにして、
全置換してみたらいかがでしょうか。
最初は時刻フィールドにして計算値自動入力＋既存値置き換えにしていたのですが
インポート時の計算では正しい結果が出ず
計算値自動入力・既存値置換
でも、その計算式の引数にリレーションの参照フィールドが有ると
再計算してくれませんね。
開始時刻の逆順でインポートしたら計算してくれるかな？？
Offline
3000～4000件で30～40分かかること自体が奇妙に見えます。
実ファイルを見れば何か言えるかもしれませんが、
不要に計算フィールドを用いている箇所などあるのかも知れません。
その上でアイデア程度ですが、処理の段階を分けてみてはどうでしょうか。
まず、作業が"走行"のレコードだけに絞り込んでおき、
日付=日付
車番=車番
開始<=開始
終了>=終了
No≠Noといった自己リレーションを通じて、休憩等の運転に付随するレコードへ、属する運転のNo.を持たせます。
後は、運転No.を用いたシンプルなリレーションシップで実走行時間が算出できます。
私なら休憩等は、上記No.の処理後に別テーブルにインポートしてしまいますが、
自己リレーションでも問題というほどの問題は無いと思います。
別テーブルにインポートし直すなら、上記のようなレコードの下処理は、
実運用のファイルではなく下処理用の専用ファイルで行った方が、
破損や肥大化などへの対処がしやすいです。
作業に当たるものとして
「走行」以外にもちゃんと発着地のデータを持つ「荷積」「荷卸」のレコードがあります。
また「走行」のみ道路区分Fが「高速」となっているレコードがありますが、
これも休憩と同じように発着地が処理的に同じ扱いになっているのでルート別に検索できません。
「高速」レコードが持つ距離は「一般」の走行距離に含まれていないので、
これをもうひとつの置換処理で「走行」のレコードに加算します。
また、休憩に当たるものとしては
「休憩」と「待機」があります。
計算値自動入力・既存値置換
でも、その計算式の引数にリレーションの参照フィールドが有ると
再計算してくれませんね。開始時刻の逆順でインポートしたら計算してくれるかな？？
インポート順に付くNoを見ると「休憩」の方が「走行」よりも先にインポートされているので計算してくれても良さそうなのにしてくれません。
集計F作らずにSum()使ってるのが良くないのか･･･
「走行」のレコードだけを対象レコードにして、
全置換してみたらいかがでしょうか。
「作業」に当たる「走行」「荷積」「荷卸」に絞って置換を行うのも考えたのですが、
「休憩」「待機」を合わせても全体の１割程度にしかならず根本的な対策としては･･･
･･･とここでふと気になりましたが、荷積荷卸のインポート後のデータを改めて確認すると「時間」と「実働時間」が全く一緒なようです。
「走行」だけに絞ると全体の５割ほどになるので単純計算で処理時間を半減できそうですね。
アドバイスありがとうございます。
･･･人にモノ尋ねる前に手元のデータを精査すべきですね^^;
3000～4000件で30～40分かかること自体が奇妙に見えます。
実ファイルを見れば何か言えるかもしれませんが、
不要に計算フィールドを用いている箇所などあるのかも知れません。
私にも不思議なんですよね。
計算フィールドはリレーションに使う「休憩」など値固定のものと、日付に対してソートしたデカルト積の自己リレーションからLast()使って最新日を割り出すものくらいしかなく、
実際インポート～加工までの処理は５分足らずで、最後二回の全置換だけが異様に遅いのです。
その上でアイデア程度ですが、処理の段階を分けてみてはどうでしょうか。
まず、作業が"走行"のレコードだけに絞り込んでおき、日付=日付 車番=車番 開始<=開始 終了>=終了 No≠Noといった自己リレーションを通じて、休憩等の運転に付随するレコードへ、属する運転のNo.を持たせます。
後は、運転No.を用いたシンプルなリレーションシップで実走行時間が算出できます。
これすごくいいアイディアですね。リレーションがかなりシンプルにできそうです。
チポ様の案と合わせて取り掛かってみようと思います。
ひとまずお礼まで、ありがとうございます。
honda様の仰られるように関連するNOを設定する方法を試してみましたが相変わらず、
それこそ20件弱のレコードの処理すら目に見えるほど遅かったです。
流石に変だと思ってリレーション条件を外したり付けたりして調べてみたところ、
開始と終了を条件に入れると遅くなることが分かりました。
実はこの二つ、元のcsvがタイムスタンプ形式だったのでそのままタイムスタンプ形式として取り込んでいたのですが、
ふと思い立って新たに時刻形式のフィールドを二つ用意して開始と終了の値を自動入力させて処理してみると拍子抜けするほど早くなりました。
処理は早くなったのでひとまず良しなのですが、タイムスタンプってそういうものなのでしょうか？
何だか凄く釈然としません･･･(´・ω・｀)
気分はどうあれ早くなったので解決とさせていただきます。
アドバイスをくださったお二方、おかげで解決に向かうことができました。
ありがとうございました！
問題の切り分けに役立てたようで、なによりです。
ただ、タイムスタンプの照合の遅さは、私も謎です。
照合条件としては扱いにくくログ以外にタイムスタンプをあまり使わないためか、
私の方ではこれまで同じ状況に出会していません。
が、FileMakerのタイムスタンプは0001年からの秒シリアル値なので、
リレーションシップで遅くなる要因が思い付きません。
あるとしたら、CSV時点の表現に、何か文字列が混入しているとか、そういう辺りでしょうか。
まさか、シリアル値としての解釈が取り込み時に保存されない、とかないでしょうし。
同じ構造を新規ファイルで再現すれば、再現しない可能性もありますね。
Pages: 1
[ Generated in 0.008 seconds, 7 queries executed - Memory usage: 549.35 KiB (Peak: 569.89 KiB) ]