SAP HANA関連を少し書こうと思う。(あらびきです。最新は違うかもしれない)
SAP HANAを語るうえで、エンジンの存在があります。
A : Join Engine
マスタテーブル同士を表結合する。(Join)
B : OLAP Engine
トランザクションテーブルを集計する。(Group by)
トランザクションテーブルとマスタテーブル群を表結合する。(Join)
C : Calculation Engine
こまいいろいろ。Union含むJoinやCaseなど．．．
D : SQL Engine
スクリプトベースのSQL文
そして、OLAP Engineに汗をかかせると、SAP HANAは無理なく軽やかに動作する。
厳密ではないけれど、だいたい以下Viewが各エンジンに対応する。
SAP HANA SPS10くらいまで、
HANA information View:HANAユーザで動作
A : Attribuite View
B : Analytic View
C : Calculation View
SAP HANA SPS10〜12およびSAP HANA2
HANA information View:HANAユーザで動作
A ; Calculation View - Dimmension
B : Calculation View - Cube - Star join:on
C : Calculation View - Cube - Star join:off
ABAP CDS View:Netweaver(ABAP)7.4以降:SAPユーザで動作
(少々乱暴です。実際はSQLエンジンで動作)
A : Basic View
B : Composite View
C : Consumption View
ちなみに、処理速度は、HANA information Viewがもっとも高速で、
Open SQL(ABAPエディタで書くやつ)とABAP CDSはほぼ同じ(誤差の範囲)です。
恐らくですが、営業的な都合でABAP CDS万能論が出ているようです。
実際、99%以上はOpen SQLまたはABAP CDSで事足りますが、
処理速度のみを追求するとHANA information View一択になると思います。
10億レコードの集計とか．．．上手に作ると十数秒で戻ってきました。(爆)
少し毒を吐きます。
上記内容は、眉間にしわを寄せて(笑)語るといいかも。
なんかね、どんな技術で実装しても、本質的な部分では変わらないのに、
SAP HANAで実装すると、アカデミックになり、
Microsoft Accessで実装すると、小馬鹿にされる。
じゃぁ本質ってなんだよ。
個人的には、データの処理単位とこれに伴う設計の違いだと思っています。
ABAPや他の言語、JavaのORマッパーやdotNETのレコードセットっと言ったほうが通りが良いかな？
これら言語の一般的なプログラマーは、データセット(内部テーブル)をデータベースから取得して、
ループを回しながら、行単位で処理を記述すると思う。
しかしながら、SQL、HANA View等は、データセットを一括で処理しようとする。
(DBカーソルとかあるけれど、基本的にループを回さない)
以下書籍のコラムに、
https://www.amazon.co.jp/dp/4774173010/
SQLを設計した頭のいいお兄さんは、
行単位でループを回すような処理は行わなくても、
あらゆる機能は実装可能なんだっというような内容を主張していて、
だからSQLは、カーソルの機能は貧弱なんだとのこと。
僕も全てでは無いけれど、ほとんどの処理をループ無しに記述するように、
脳内矯正をしています。
理由というか好き嫌いなんだけれど、
SQLでデータセットを一括処理させると、
バグが発生したときに、派手な動きとして現れるので、(レコードが大量増幅したり)
見つけやすいと思う。
あと、だいたいにおいてローコストでパフォーマンスが良いと思う。
検索キーワード
ABAP
ABAP 7.4
ABAP 7.40
ABAP 7.5
ABAP 7.50
Netweaver 7.4
Netweaver 7.40
Netweaver 7.5
Netweaver 7.50
Open SQL
New Open SQL
Classic Open SQL
SAP HANA
HANA VIew
CDS View
ABAP CDS View
Code to Data
Code Pushdown
以上
