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.最近はこんなのを聴いています。悩むイヤーパッドが劣化していて、社外品に交換して使っていました。時系列を辿ると以下の通り。?https://daih73.hatenablog.jp/entry/2019/10/23/004534ヘッドホン:ようやくバランス駆動で聴いてみた!https://daih73.hatenablog.jp/entry/2019/12/04/015908を経て、実は困った事態になっていました。左右のバランスが合っていないような気がする。アンバランスワイヤレスの時はセパレーションが普通だったのあまり気にならなかったのですが、バランスワイヤードにすると、セパレーションが良好なので、左右が合わない。