JSON”を付与すればクエリ結果をそのままJSONに出来るんですって!?そんなこと知らずにDapperでガリガリとSQLをパースしてJSONを作っていたとか馬鹿丸出しですねワタシ。パトラッシュ・・次から頑張るよ・・・・。いうことでSQLだけで多層ネストJSONが出来るまでを検証しました。以下にその方法を示します。(テンプレートの”AdventureWorkLT”を利用)このサンプルデータを利用して「セールスの存在する顧客別にオーダーとそのオーダー詳細を表示する」という3層ネスト構造を再現します。SQLで表現するとこんな感じです。CUST.CustomerID,SHDR.SalesOrderID,DETL.SalesOrderDetailID実行するとこんな感じ。DATABASEの基本機能だけしか使いません。AUTO”を付与すればめでたく解決・・・ではなく、ここからネストさせたい階層ごとにサブクエリを定義していく必要があります。それをストアドファンクション化したのが以下となります。@json;ENDポイントは次の通りです。PATH”とする(PATH付けないとコケる)ROOT(‘INFO’)とすることでルートオブジェクト配列にアクセスしやすくするサブクエリでのエイリアスがJSONでの型名となるこうして作成したJSONをオンラインパーサーで確認するとちゃんと3層ネスト構造となっていました。APIの作成完了なのです。余談ですが逆にSQLだけでJSONを解析することも可能です。numeric(38,6));実はこの逆変換の方が大変でした。ポイントは次の通りです。APPLY”しても展開元のエイリアスは呼べる(これになかなか気付かなかった・・・)今どきのSQLServerってこんな感じでSQLを駆使していけばJSON化もパースもできるんですね。楽になった気があまりしないのは気のせいではないかもしれません。慣れてなければ面倒くさいからこれならDapper使うわってのもアリではないでしょうか。あとSQLの見通しが悪くなってるのがかなり保守観点でマイナス。「(言語名)経験○○年の要員がホゲホゲ」なんて考えのマトモにスキル判定も出来ない無能揃いのSES業者が「運用でSQLバリバリやってましたHAHAHA」という定型作業しか経験のない人材を押し込んでくることになりかねないので要注意です。BYもできない、トランザクションスコープも適用されないという非常に癖のある代物でした。オールドタイプにはなかなか馴染めないですね。トランザクションスコープは面倒で、ストアドプロシージャを経由すればパーティション単位でトランザクションが保証されるというものです。ちなみにストアドプロシージャの実装方法ははAzureポータル上にてJavaScriptにより定義する必要があります。仕方がないと諦め、ベタ書きでJavaScriptを書いてストアドプロシージャを作成します。テストデータでは”uniqid”でパーティション化されたコレクションを想定しています。return;}次に利用側のコードを書きます。DBにアクセスします。}}指定したパーティションキー値と投入データの値が一致しない場合はストアドプロシージャの呼び出しは失敗します。Keys)設定を行い、ストアドプロシージャ側に主キー重複時の例外処理などを実装する必要があると思います。ストアドプロシージャを経由する追加処理は非常に遅く、あくまでもトランザクションを必要とした少量データの更新などにしか使えません。大量データの取込にはBulkExecuterライブラリを利用して一気に追加/更新をやるのが本来望まれる処理のようです(ただしV1限定)。