ORMめんどくせぇって思った人のカンニングサイト(特にDjangoの変換サイトほうは、かなり使えそう)
SQLが書ける人が
SQLで書いた方が早いわ、めんどくせぇえって思った時のカンニングサイト
DbeaverなどでSQLを作って、このイメージでORM書けたらいいんだけどな。
その書き方、どうやんのか、試行錯誤するのが、メンドイから、自動変換できたら、ええなぁ
って、思ってる人のためのサイトです。
変換サイトの紹介(Laravel用)
Laravel用
＜私の感想＞
こっちはイマイチな感じっす
SQLそのまま。無理くり、Laravelのコードにしましたって感じがするです
通常的なアプリ開発時のコードとは程遠い
ただし、マイグレーション定義時のPK, FKの指定を効かせた通常的なやり方が使えないような
イレギュラーなクエリが、どうしても必要になったときの奥の手としては、使えそうだ。
変換サイトの紹介(Django用)
Django用
＜私の感想＞
こっちは、いい感じっす
上記の「＜私の感想＞」になった理由(Laravel側)
Laravelでアプリ開発時は、
マイグレーションの定義時に、PK, FKの指定をきちんとやっていたら、
Eagerローディングなどの便利機能でインピーダンス・ミスマッチがあまりない感じのオブジェクトの構造でそのまま、取得できたりする
そもそも、SQLのINNER JOINや、LEFT JOINの違いみたいな概念がない( そのような概念が必要ない )
補足）
JOIN元のオブジェクトがJOIN先のオブジェクトをコレクションで保持する構造
JOIN先がない場合は、JOIN先のコレクションが空になるような構造
そのため、SQLのINNER JOINや、LEFT JOINの違いみたいな概念がそもそもないように見える
ただし、SQL的な構文をそのままでの実装方法もLaravelにはあるようだ
上記の変換サイトでは、そちらの実装方法を出力している
それゆえ、上記のサイトでSQLを機械的に変換してしまうと、通常のアプリ実装と程遠いコードが吐き出される
だから、上記の変換サイトに対する＜私の感想＞はイマイチということになる。
ただし、「イレギュラーなクエリが、どうしても必要になったときの奥の手としては、使えそうだ。」
上記の「＜私の感想＞」になった理由(Django側)
Djangoでアプリ開発時、
DjangoのORMは、 SQLの INNER JOIN や LEFT JOIN を専用の構文でサポートしているため、
RDBの仕組みをそのまま反映した設計になってるように思えた
「データベースの考え方に寄せた構造」であり、インピーダンスミスマッチを解消せず、
許容しているように感じられた。
それゆえ、上記のようなサイトで、機械的な変換を行っても
普段のアプリ実装で、使えそうなコードが吐き出されるのではないかと考察している
だから、上記の変換サイトに対する＜私の感想＞は「いい感じ」ということになる。
Discussion