Dataと言おうが、データーベース様には迷惑をかけられない!!!データーベースはそっとしておきたい!!(本音では)データーベースを信じてはいけない!だって、BSEGで先輩たちに怒られ続けたから。こんなところでしょうか?だから、ITABにせっせとマスタ情報を溜め込む。ENTRIESを使って。ENTRIESを使うために。準備をして、準備をして、確認して、確認して、えいっ!!てね。業務ロジックに無関係のコードがたくさん生まれる。データの並び順に細心の注意を払って。SEARCHを使うために下準備を念入りに。時代は流れてHANAでABAPが動く。やめようよって思います。Pushdownって言う遥か前から、一般(非ABAP)と同じようにデータベースにおまかせしようよ。昔々ORA7とかの頃は信じてはいけなかったかもしれないけれど、もう信じようよ。TABLEを含めてすべて書き換え可能と教わりました。SQLで書かれていました。それと同時に、制約事項もたくさん書かれていました。気にしなければいけないことが多いのね。そこで、これまた先日見つけた必殺技。@ITAB」これ行けます。@ITAB」で書き換え可能です。使うための下ごしらえもほぼ不要。一時テーブルという仕組みがあったことを改めて思い出しました。Viewの途中を覗き見するときに、知らないうちに使っていたよな。7.52から追加されたWITH句もHANAでは一時テーブルが動いていると考えると辻褄が合うと思います。プログラムの説明3種類の方法で、外見上の振る舞いが同じになるように、実装しています。IN句でマスタデータをフィルタし取得します。SEARCHでマスタ情報を特定して、各種名称を補完します。IN句の直前で、ブランクチェック、SORT命令DELETE命令による重複削除します。SEARCHの手前で、SORT命令による並び替えをします。WITH句の前半で、トランザクションデータの重複削除します。JOINすることでマスタデータのフィルタ取得および、並び替えをします。SEARCHでマスタ情報を特定して、各種名称を補完します。直前の、ブランクチェック、SORT命令DELETE命令による重複削除は不要です。本来あるべき姿マスタ情報は、SELECT文のJOIN句で表結合します。パフォーマンスについて約4万件取得で、いずれも0.06~0.07secでした。JOINによるパフォーマンス悪化を懸念する人がいると思います。以前、単一トランザクションテーブルに対して、約30のマスタテーブルをJOIN句結合しました。パフォーマンス悪化は無かったです。(1秒以内で処理終了していました)データベースの並列実行に対するパフォーマンス悪化を懸念する人がいると思います。数年前に測定したところ、感覚値として50並列位すると、処理時間が1.5倍程度になります。HANAのパフォーマンスを遊ばせるのは、エンドユーザの利益と相反すると思います。ソースコード保守性Cの「テーブルJOINでテキスト情報を取得」が圧倒的大差で、コード量が少なくなります。(256行→62行:なんと1/4以下!!!)コード量が少ないと、バグの入り込む余地が大幅に減ります。影響範囲についても、そもそもコード量全体が少ないので、問題にはならないと思います。苦手な人は、ご自身のバリューを保つため、勉強しましょう。0.ENDFORM.最近はこんなのを聴いています。知的好奇心でVBAに続きABAPでも書いてみました。みたいな月別アーカイブはてなブログをはじめよう!dai_h_73さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。