Asakusa Framework Advent Calendar 2019の24日目、SQLをAsakusaFWに変換するポイントについてです。
SQLのUNIONには、「UNION」と「UNION ALL」があります。
UNIONは重複データが有る場合はそれを排除して1レコードのみ出力しますが、UNION ALLは重複があっても構わず全て出力します。
UNION ALLはAsakusaFWではcore.confluent演算子がすばりそのものです。
UNIONは重複排除をするので、MasterCheck演算子で（全カラムをキーとして比較し）存在しないものだけ出力すれば良い、ような気がしますが、厳密には違います。
s1 UNION ALL s2 UNION s3の様に、複数のSELECTをUNION ALLでつないで最後だけUNIONになっている場合、それまで重複ありで複数レコード出力されていたものが、最後に重複排除されてしまうのだそうです。
そのため、UNIONはFold演算子で（全カラムを集計キーとして使用し）集計キー毎に1レコードだけ出力するのが良さそうです。
Asakusa Framework Advent Calendar 2019の23日目、SQLをAsakusaFWに変換するポイントについてです。
SQLでサブクエリーと並んで少々やっかいな（と思う）のが、row_number等の分析関数です。
これはGroupViewで簡単に…というわけにいきませんが、GroupSort演算子を使えば実現できます。
複数の分析関数が使われている場合、パーティションキー（集約キー）とソートキーが同一であればひとつのGroupSortで実現できると思いますが、そうでない場合は、複数のGroupSortを使わざるを得ないでしょう。
Asakusa Framework Advent Calendar 2019の22日目、SQLをAsakusaFWに変換するポイントについてです。
SQLで結構やっかいなのが、サブクエリーです。SELECT句やらWHERE句やら、値を書ける場所ならどこにでも書けるSELECT文です。
スカラサブクエリーなら取得できるのは1件だけなのでまだましですが。
サブクエリーをWHERE条件で結合している場合、AsakusaFWではそれが結合キーになります。
サブクエリーのデータの量が少ないならGroupViewを使うのが一番簡単です。GroupViewならConvert演算子やBranch演算子でも使えるので。
そうでなければ、ConvertやBranchの前にCoGroup演算子等でサブクエリーの値を取得・結合する形になるでしょう。
複数のサブクエリーがある場合、結合キーが1種類で済むならCoGroupひとつでいけますが、そうでないなら、サブクエリーの数だけCoGroupが必要となり、あまり好ましい感じはしないのですが、仕方ないですね＾＾；
Asakusa Framework Advent Calendar 2019の21日目、SQLをAsakusaFWに変換するポイントについてです。
SELECT文のLIMITは（標準SQLなのかどうか知りませんが）、出力するレコード件数を絞るものです。
ORDER BYでソートした後に件数を絞るとすれば、AsakusaFWではGroupSort演算子が相応しいです。
OracleにはLIMITは無く、WHERE条件でROWNUM擬似列を使うのが常套手段だと思いますが、AsakusaFW化する際はLIMITと同様の扱いにする方が楽でしょう。
なお、LIMITではキー毎の件数制限は出来ないと思いますが、GroupSort演算子ではそれも簡単です。
Asakusa Framework Advent Calendar 2019の20日目、SQLをAsakusaFWに変換するポイントについてです。
SELECT文のORDER BYは、出力結果をソートするものです。
AsakusaFWで結果をDirect I/Oでファイルに出力する場合は、ExporterのgetOrderメソッドでソートするカラムを指定します。
AsakusaFWのOperatorの各メソッドの場合は、出力データに対してソートするわけではありません。ここはSQLとは異なります。
CoGroup演算子とGroupSort演算子では、入力データに対してソートすることが出来ます。これらの演算子への入力がORDER BY付きのSELECT文の場合は、ソートカラムをCoGroup/GroupSortの入力データの@Keyのorderに指定します。
それ以外の演算子ではソートすることは出来ません。基本的に分散して処理する演算子ばかりなので、そもそもソート順を指定することは出来ないんですね。
