PL/SQLのアドバイスをお願いします。

主にオラクルのデータをAccess2000からレポートして使っています。

〒コードが、数字データで保存してあります。
例）3430123

今はクライアントPC側のAccessで
例) 343-0123
と計算させて利用しています。

こういった計算はオラクル側でPL/SQLなどを利用したほうが効率はいいでしょうか？
それとも毎回計算させるのであれば、クライアント側かサーバ側で計算速度に違いはありませんでしょうか？

※実際にはオラクルの〒コードのフィールドが数値になってしまっているので、

コードが５～７桁とデータがまちまちになってしまっています。
例）北海道 0013304 → 13304 (とオラクルで保存)

データを利用するとき、５桁と判断して001-3304 と計算させています。
00で始まる番号、0で始まる番号、0以外で始まる番号の３種類データがあります。

まだ、PL/SQLを利用したことがないのですがこれから活用しようと考えています。

No.4 ベストアンサー 回答者： GoF 回答日時： 2004/10/05 15:19

もし力技でよければ

translate(to_char(postal_no, '000,00000'), ',_','-')

で生成できます。↑の',_'のアンダーバーは' 'にしてください。

ユーザ関数などを使って
NUMTOPOSTALCODE関数などで覆い隠さないと
一見して何を意図しているのか分かりません。
要注意なコードの一つの例みたいものですね。

速度に関しては、この程度では大して変わらないと思います。
但し、レスポンスに非常困っている、大量のデータを一気に処理している
明らかにクライアントは時代遅れのマシンである。
を満たす場合には「やってみますか？」程度だと思います。
ちなみビューをかますと、レスポンスがガタ落ちすることが多いので安易な利用は控えたほうがよいです。

この回答へのお礼

アドバイスありがとうございます。

本来ならフィールド定義を変更したいとことですが
カスタマイズされたアプリケーションが動作しなくなる
ことが分かったので、計算させるしかないのが現状です。

translata...
を使えば、データの桁数に係わらず対応出来ますね。

工夫して試してみます。

お礼日時：2004/10/05 17:29

No.5 回答者： asianttw 回答日時： 2004/10/10 03:50

状況は完全には分かりませんが、、、

可能であれば、カラム自体をVARCHAR2に変えてしまうべきでしょうね。データ件数が膨大で処理が重いということであれば、スナップショットを作ってしまうのが効果的だと思います。
SQL_PLUSは基本的にサーバでのデータ処理に使うのが有効だと思います。

No.3 回答者： mitoneko 回答日時： 2004/10/05 00:09

　（ベーステーブルの構造は修正してはならないという条件付きで）

　計算速度的には、どちらでやっても似たり寄ったりだとは思います。
　クライアントのデータ処理の方が多様になる傾向が大きいように思うので、どうせ必ずしなければならないなら、私は、サーバー側で処理してしまいます。デコード関数をＰＬ／ＳＱＬで作っちゃって、ビューをかぶせてしまう形になるでしょうか。
　そうしておけば、将来、違うレポートで使うなどの場合でも、変換処理のことは二度と考えずにすみます。

この回答へのお礼

ビューについてのコメントを頂いたので試してみました。

いままで全然利用していなかったのですが、場合によっては効果がありますね。

クライアント側の処理をビューで持たせたところ処理時間が1/3～1/4になりました。

ありがとうございました。

お礼日時：2004/10/08 15:30

No.2 回答者： shangzi 回答日時： 2004/10/04 19:45

私の場合そう言う時にはオラクル側で、

declare
A varchar2(7); --オラクルDBの郵便番号の文字型
B varchar2(8); --Accessに引き渡す郵便番号
begin
A := lpad(to_char(郵便番号),7,'0')　--郵便番号を文字型に変換し7桁0埋め処理をする
　B := substrb(A,1,3)||'-'||substrb(A,4);　--ハイフンを付与する
end;
とSQL関数で対応しています。
　簡単な処理ですので速度的にはAccess側、ORACLE側どちらで処理しても、問題にはならない程の速度で処理できるはずです。
　構造上では、不正な型で格納しているのはOracle側なので、成形した正しい型のものをAcsessに渡してやるのがいいかも知れません。
　見当違いの答えだったらごめんなさい。

No.1 回答者： orangemikan 回答日時： 2004/10/04 17:04

こんにちは

オラクル側で数値データで保存してあるのは悲劇ですね。

クライアント側かサーバ側のどちらが効率的かということですが、クラアントがたくさんあるなら、サーバで集中させて処理するより分散したほうが計算速度は速いと思います。
ただ、オラクルはPL/SQLなどで引数が違うだけのものは解析してメモリにキャッシュしておくので毎回計算といっても、実行文→解析→実行 ということはやってないません。

しかし、今回の場合ですと簡単な処理なのでどっちでもいい気がします。^^;

私がやるならオラクル側のテーブルの変更をするか、ビューを作ります。

ただPL/SQLは便利なので勉強を兼ねて利用することをオススメです！