過去の桐井戸端ＢＢＳ　（桐ver.８）
7357 併合処理が遅いのですが… ちえこ 2000/08/28-15:46
こんにちは。桐初心者ですがよろしくお願いします。
６００件～１０００件程度の表と、１２万件程度の併合元表で、
郵便番号、住所１(市区まで)、住所２(町名まで）の併合(照合）をしているのですが、処理に１０数分かかります。
他の人にきくと、そんなに遅いはずはないというのですが、何か設定がおかしいのでしょうか？
どうすれば早くできますか？
桐はＶｅｒ８を使っています。
7368 Re:併合処理が遅いのですが… 宮城 2000/08/28-21:27
記事番号7357へのコメント
ちえこさん、こんにちは。何をされようとしているのか、ちょっとはっきりしないところもありますが、
郵政省郵便番号データ（ちょうど１２万件ぐらいですね）を元に、郵便番号で照合させ、
住所データを複写しようとされていると仮定します。

当然郵便番号による索引による並び替えは実施されている、と。

私の経験では、こんなもの相手に「併合」しますと、１０数分で済むというのが信じられません。
いくら表引き用にシンプル化をはかっても１時間くらいかかるのではないでしょうか。

表引きのほうがまだましでしょう。
それも項目計算式でやると、入力のたびに時間がかかると思いますので、一括処理に書くか、
Win桐の式記憶機能を利用し都度置換します。

なお、郵政省データは相当問題が多くかなり加工しないと使用に耐えません。

7371 Re:併合処理が遅いのですが… 佐田　守弘 2000/08/29-02:36
記事番号7357へのコメント
ちえこさん
私は、正しい表引き元表(郵便番号表)と適切な索引を設定する事によって、数秒程度に短縮できる可能性があるのでは
と思っています。
ただし、処理時間には様々な要因が絡みます。
①索引の設定
表引き元の表(この場合は郵便番号表でしょうか)に、照合項目に対する索引が設定してある事が重要です。
これがあるとないとではおそらく３桁くらいの速度差が出て来るでしょう。
併合の操作では、併合先の表を上から順にナメながら、そのレコードの照合項目に合致するレコードを併合元の表から
検索する操作が行われます。
この時の検索に使える索引があれば、ほとんど瞬時に検索できますが、索引がないと併合元の表(この場合12万件)を
毎回上から順に検索し始めます。
大ざっぱに12万対1（本当はもう少し大きい）程度の違いになります。
②併合先の表の形
どの様な表に併合するのか、併合する際にページ分割が発生しないかどうかなど、チェックする余地があります。
これは意外と影響します。
③ハードウエア環境
CPUの速度やメモリのサイズ、HDのアクセス速度なども影響するでしょう。
ハードウエアのスペックでも１桁の差が出て来ます。

●郵便番号データはどの様になってますか？
宮城さんも指摘されていますが、どの様な郵便番号データを使っているでしょうか。
郵政省のCSVデータを読み込んだだけのもの、ないしは、どこかのソフトに付属の
古い郵便番号データを転用したのであったら、多分、アウトです。

●併合先の参照項目の値は正しいですか？
郵便番号で照合するのか、住所で照合するのかが書かれていませんが、
いずれにしても、索引を使って唯一に照合できる形に記述されているでしょうか。
（意外とこの点は落とし穴になっています。）

●結論的には
私は条件をきちんと整備すれば、数秒で併合処理ができると思っています。
ただし、その整備をきちんとすることが結構な難題で、これができなければ、索引も有効に働かず、
場合によっては数時間以上の処理が掛る事もやむを得ないと思います。
このあたりは、実際のハードウエア環境とデータを拝見していないので、何とも言えません。
私が思う「数秒でできる」は間違っていないと思いますし、宮城さんが書かれている「１時間以上掛って当然」も正しいと
思います。
そう言った意味では、１０分台で処理できれば「まずまず」なのかも知れません。

佐田守弘(KS-00119)
7379 速くなりました！ ちえこ 2000/08/29-10:36
記事番号7357へのコメント
宮城さん、佐田さん、説明不足の質問にもかかわらず、アドバイスありがとうございました。
私のやっている処理は、郵便番号、住所全て入力済みの表(住所録等）と郵便番号表を照合して、
合致しないものを絞り込み、入力ミスをチェックするものです。
「索引を設定する」ということも知らなかったのですが、併合元表の郵便番号表に索引を設定したところ、
併合処理が数秒でできました！
本当にありがとうございました。また初歩的な質問をするかもしれませんがよろしくお願いします。

7391 併合処理における索引の設定 佐田　守弘 2000/08/29-18:36
記事番号7371へのコメント
既に質問者のちえこさんの法では解決されているようですが、
#7371にて書きました点に誤りがありましたので、訂正方々、確認試験結果の報告をさせて頂きます。
●併合時の索引設定
併合時に設定する索引は、併合先表の照合項目に設定して下さい。
そして、併合元表は絞り込みなどを解除した状態で行って下さい。
具体的な例で言えば、住所録の住所を郵便番号を照合項目として、郵便番号簿の住所で併合操作をする場合、
住所録の郵便番号の項目に索引を設定しておきます。
そして、索引があればよく、並べ替えを行っておく必要はありません。

●併合速度の試験結果
私の名刺管理データを使って、併合速度の試験をしてみました。
・併合先表：名刺管理データ（実データを町名で単一化し、1284件を用意）
・併合元表：全国郵便番号データ事業所も含めて約12万件以上
　　（郵政省提供6月度データを元に表引き用に変換したもの）
【結果】
併合は、郵便番号を参照項目として町域名を輻射する場合と、町域名を参照項目とし
郵便番号を輻射する併合する場合とを調べました。予測に反してどちらの併合も同じ速度で、次の通りでした。
・IBM 560X(MMX 200MHz メモリ 32MB WinNT) 23秒
・EPSON Endevor Pro(PentiumⅢ 450MHz 同256MB Win98) 16秒
以上の通りで、併合にはマシンの性能はほとんど影響しませんでした。

なお、上記の索引を設定しないで併合を行うと15分以上掛った様です。
（終了時点を確認できなかったため正確な時間は分からず）

佐田守弘(KS-00119)

7396 Re:併合処理における索引の設定 yasuyukis 2000/08/29-19:24
記事番号7391へのコメント
併合先表に適切な索引を設定していても、
併合先表を絞込状態にすると、
とたんに併合速度が落ちますよね。

これは、何とかならないかといつも悩んでいます。

7404 Re:併合処理における索引の設定 悲しげ 2000/08/30-00:40
記事番号7396へのコメント
どもっ、yasuyukisさん、

>併合先表に適切な索引を設定していても、
>併合先表を絞込状態にすると、とたんに併合速度が落ちますよね。
>これは、何とかならないかといつも悩んでいます。

絞り込み状態と云うのは、一種の「別表」として扱われていると見なした方がいいと思います。
この状態は、当然、索引も何もないスッポンポンの状態にありますから、
これを使った併合は無索引状態で行われるので遅いことになります。

さて、別の書き込み（削除済かも）で私は、併合元と併合先とを途中で錯乱してしまいましたが、
ここで云う併合先を絞り込み状態にするのはどのような理由でしょう。
用途によっては対応策があるかもしれません。
１）もしこの時の併合が「置換」であり、絞り込んだ状態で（一部のレコードのみ）置換したいと云うことであるのなら、
「併合」ではなく「置換　#表引き」が使えそうです。
ただし、この場合はこちらの表（併合先表相当）は絞り込み状態だろうが何だろうが、
ともかく無索引状態で構わないものの、表引き元表（併合元表相当）の方は
しっかり索引が設定され且つ利いている必要があります。
この関係はあたかも併合とは逆になります。
２）併合「選択」ならば、絞り込み→併合選択と云うよりは、絞り込まない（索引が利いている）状態で
併合選択してから必要な絞り込みを行う方が速いかもしれない。
３）この併合は、絞り込み状態で実行したいと云うことから、「挿入」を含むものとかダイレクトな「削除」ではないですよね。

何れにせよ、目的次第では別なアプローチがありそうにも思えます。

戻る