DSLやめてSQLでいいんじゃない？

ORMはCUD処理は得意ですが、R（SELECT）処理は苦手です。 DSLのゴールはSQLへの翻訳であるのに、答え（SQL）を知っていても、わざわざ逆翻訳（DSL）しなければならない。 その上、各ORMライブラリごとにDSLの文法は異なり、SQL以上に方言だらけの世界です。 そこで改めて考えたい。なぜSQLを使わないのですか？ SQLを忌避する理由 私が想像する理由は大きく5つあります。 SQLインジェクションが怖い 汎用性が低い 静的解析やコンパイルチェックが効かない エンティティモデルへのマッピングが面倒 長文の保守性が悪い これは今も本当に問題なのでしょうか？ SQLの解析、加工が出来れば解決しませんか？ 問：SQLインジェクションが怖い メンバーのスキルによってはちょっと怖い。 SQLを文字列連結するのは危険。 答：SQLと検索条件を合成できれば心配ない SQLを解析、加工できれば

[gnety]

ORMを使うと1つの問題が2つに増えることが多い。結局SQLをそのまま使った方が保守性も高くわかりやすくなる結果に

[zentarou]

そのモデルやらスキーマ情報やらマッピング定義やらもDSLと同じじゃないの？

[circled]

多機能なPostgreSQLとか使ってるとORMが対応してなくて生SQLになりがちなのと、フレームワークとかが提供するORMの寿命よりもDBの寿命の方が長いので、結果SQLの方が確実に生き残るんだよね。つまりORM学習コストが無駄に

[versatile]

2000行とかある SQL を見なければならない人は案外多い

[s_rsak]

確かにORMで目当てのSQLを作れなくてイライラさせられるし、ドキュメント読んでもやり方が見つからずどんどん時間が無駄になる

[tofu-kun]

生成AIの活用を考えるとDSLよりSQLの方が精度が高い…という話ではなかった

[strawberryhunter]

実行時に全部やるタイプか。①SQLを用意して②パラメータ定義を用意して③new SqlParamInjector()して④SQLにパラメータを渡して⑤new SqlFormatter()して、SQLとパラメータを得て、⑥そこから実行するのかな。う、うーん。

[NetPenguin]

CUDはORMが強いけど、R=SELECTはSQLの強さをもっと使っていこうよ！という事だとすれば、CQRSとかであるように複雑な検索とかはクエリとしてSQLゴリゴリ使うで良いんじゃないかな？

[System]

ClojureのHugSQLが丁度いい。

[meonal]

別にどっちかに統一する必要ないよね。explain analyzeでチューニングするクエリはSQLからORM逆算するのはマジで無駄だし追加や更新はいちいちSQLで書きたくないし。

[daichirata]

複雑なクエリの時は普通にSQL書いてシンプルな奴はORMのメソッドで、モデルへのマッピングはどっちもORMでって感じでやるから正直そこでそんなに困った事無い気がする

[ledsun]

SQLは汎用性が高すぎる。アプリケーションに合わせてある程度制限したい。

[HAZI]

ORMで部分的にSQL書ける機能あるから大体それで事足りてる

[toaruR]

たまにORMがバグっててなぁ(ノ∀`)

[cl-gaku]

MyBatisいいよね

[toro-chan]

今のところ賛同できない。SELECTは3重ぐらい入れ子になってからがスタートだ。どこに何の条件を入れるかを可変にせざる得ないときは全然だめだろう。簡単なselectだったらDSLで問題ないのでは。

[aiya000]

別解「直接GraphQLをサーバー・言語として使う」 https://chatgpt.com/share/6842f9d9-f180-8005-8f23-f4350b3117ce 「このGraphQL構成ではパフォーマンスチューニングに劣る」はそうだけど、今回の論点に対しては答えられそう。