AIにボイラープレート書かせて生SQL回帰とか一周回って原始時代に戻った感あるわ 結局、生成された大量のコードを誰が保守するんだよっていう
好きにやりゃいいじゃん。今まで使ってた人は引き続き使う。
AIを使うなら、AIにたべさせるコンテキストを減らせるので、ボイラープレートコードは少ない方が良さそう
AI時代に、もはや関数さえ必要ない。なんならfor文さえ必要ない可能性がある。オンデマンドに実行コードを行単位で生成してくれそう。
大事なのは型安全！！！！！！！！
AIが生成したSQL文をチェックするぐらいならORMコードを生成させてチェックする方が楽だと思う派
ORMで苦労するようなSQLクエリは極力避けるべきですね。クエリで何でもやろうとする人が多いけど後で破綻するかバグの温床になる / "ORMが「SQLであればできること」のすべてをカバーできない問題"
ドメインが複雑になると普通にAIもSQLとか書き損じるからな。ただ多少の冗長さを許容しても明示性が重要になってきてるとは思う
何言ってるの？🤔
弊社ではSQLを書くコード生成型のORMはうまく機能している。保守もAIがするに決まってるので、一番うまく機能すると思ったものを採用すればいい。保守を人間がやる前提で問題視する人の気持ちがわからん。
今の所は人のレビューが必須になるので、人が読みやすいという点は無視できない。 レビューする方々のレベルもまちまちなので、レビュー時にORMが担保してくれる事を気にする必要がない。というのは大きなメリット
「ORMなしでAIにDBアクセスコードを生成"させる"」ではなく「ORMなしでAIにDBアクセスコードを生成"する"」なんですね？ 日本語がろくすっぽ使えないやつの戯言なんぞ聞く耳持たんわ。正しい日本語で書き直せ
そもそもAI時代じゃなくても値の詰め替えが出来れば良くて、環境差異の吸収ができればもっと良くて、オブジェクトとのマッピングとかマイグレーション機能をつけだすと邪魔。
アクセスするSQLが数本ならいいけど、条件分岐が増えたときの影響範囲チェックはどうするのか問題は辛そう。 最近のreactにSQL書くやつとか、PHP時代に戻ってきてるわけだし。
Onlymapsの時代が来たか…（ORMだけどSQLはそのまま書いてオブジェクト変換だけするやつ）
“ORMが「SQLであればできること」のすべてをカバーできない問題は、20年以上あるORMの歴史でずっと解決してきていません。” ORMがデータアクセスの進歩を20年停滞させた側面あるよなぁ
”ORMなしでAIにDBアクセスコードを生成する”MCPで囲った方がよさそう。
似たような話でJSフレームワークは止めてVanillaJSで良くないですか？というのもある
このままORMの存在意義がわからないまま人生終わりそう・・・
AI時代以前からトランザクションスクリプトで書けるシステムならDAOで十分（逆にバリバリのドメインオブジェクトの場合もActive Recordを使う意味は薄い）。AI時代でTxスクリプトの適用範囲が広がったのかどうかは知らん。
だから、小さいプレハブ小屋を建てる技術と高層ビルを建てる技術って違うんだよ。ビジネスだとシステムはプレハブ小屋から始まって高層ビルまでスケールアップすることを求められる。プレハブ小屋建てて満足してろ。
ORM使ってるとだいたいどこかでイラつくし、ボイラープレートコードの大量生成をAI側でやってくれるなら全然アリだと思う。昨今のセキュリティ問題も鑑みると、依存ライブラリ減らせるのは大きいしね
SQLの細かい指定をしないといけないレベルのパフォーマンスが求められるんなら、AI 関係なしにORM入れないほうがいいと思う。そういうシステムじゃないならORMのリスクは全然気にならないよ。
AIのお陰でそもそも実は要らなかっった物が露呈してきて嬉しい。ORMなん使っててメリット感じた事無いわ。
半年ORMってろ
生SQL書くとしてインジェクションとか大丈夫なのかな。文字列連結でSQL生成みたいなコードをAIが出してくると面倒い気も。
不要な例が一昔前だし、昨今のRailsでのActive RecordやGoのgormからの置き換え例が無いと、そもそも生SQL書く手段を各種WAFが用意してないならそこからになる
動的型付け語はどっちでもOK、静的型付け語はDTO生成だけでも使いたい。AIにSQLで（しかも概念なんちゃってSQLでも通じる）「これをLinQで書いて」とか指示できて助かる。確かにViewごしに発行される実SQLがクソかったりと、
生sqlは複雑化しやすいからシンプルに済ませるガイドラインとしてORMがあるのでは
ORMのままで素直に作れるか、あるいはSQLを書かなければいけない状況がたくさんあるかによって違うのでな。。あとセキュリティのことも忘れないでください。。自分が思うよりSQLインジェクションをなくすのは忘れがち
マイグレーション管理とか結局オブジェクト変換は必要になるし、やるとしてもORM経由の生SQL呼び出しでSQLだけAIに作らせるぐらいならいけるかな
自分も似たようなことを思ってた。テストが増え、フレームワークは薄くなる。もっと根本的に変わるかもだけど。
役割が変わるのは確か。そもそもリッチなやつは流行りじゃない。でもリレーショナルデータベースと言語のマッピングという本質はやっぱり必要で、型システムとの統合などの機能は要るんじゃない？
〇〇を取得してでイケるなら
まだ、生SQL書かせるほどAIを信頼出来ない
不要です。複雑なsqlになる様な操作をORM でやると何かあった時に解析が辛いし、逆にシンプルなsql ならORM はいらない。結局欲しいのはサニタイザーとクエリビルダーレベルでいい。/ sqlc でsqlからコード生成してる
そもそもORMが...
こういう人ってプロダクションコードほんとに書いてるのか疑問だ。試作アプリならどっちでもそれなりに動けばいい。
コネクションプールの管理やらを再開発する（させる）のめんどくさくね？と思ったけど、純粋にマッピングするところの話なのかな
sqlmapperのmybatisは神だったわ 今はどうかしらんけど
複雑なsqlおよび、その周辺コードをレビューする気にもあんまりなれない。
SQLには型がないのがデメリット。AIはORMも得意なので、レビューしやすいORMの方がいい。複雑なJOINやUNIONは可読性を下げるので最低限にしたい
所謂ドメインモデルとかエンティティとかにするのでなくても result["id"] とかやりたくないので何かしらのタイプに勝手にうまいことやってくれるようなマッパーはいる。人が一切読まなくて済むならどうでもいいけど
AI時代の前から不要
>AIは生SQLを書くのが得意 >ORMが「SQLであればできること」のすべてをカバーできない問題 どちらもレビュー困難な汚物みたいなSQLが飛び出してくると言う共通点はある
CRUDな処理は誰が書いても大体同じというのが一番大きいと思う。そんなところにAIのコンテキストを使うのはもったいないと思う。
「AIに生成させた例示なので、構文が誤っている可能性はあります」同じようにSQLが誤ってる可能性は考えないのかな。それならもういっそ機械語を生成させれば
出たコードを本番品質で出せるならなんでもいい
複雑性をどこに持ってくるか。そもそもORMは使ってないけど。
ORMが不要説は一部わかるけど、AI時代を引き合いにそれを主張するのは微妙な気がする。ORMを挟むことで発生する問題の多くもAIによって緩和されるようになってるんだから、むしろORMを使うほうが良いとも言えそう。
以前に他言語バインディング生成について似たようなことを考えたが、やはり後方互換性を維持できる程度に再現性が無ければ安心して使えない。stableほげほげの類が必要。
生クエリじゃないとパフォチュー出来ないからそういう意味ではわかるけど、かといって全部パフォチュー必須でもないからそういうとこではORMで良い
先日きしだ氏の「AIがバイナリを直接吐くようにはならない」という記事があったが、SQLはバイナリほど低レイヤではないが、ドメイン知識を表すには不適なので、人間が読むにもAIにドメイン知識を伝えるにもORMは必要
今後は仕様や定義ドキュメントとしての側面が強くなるんじゃない？外部制約なしのリレーションや、複数のDBを跨いで結合する時は、モデル定義した後はよしなにして欲しい時もあるから。
どういうタイミングの未来かわからんけど、途中にはレビューしないといけないタイミングがあって、 ライブラリは一定の信頼ができる可能性がある。キャッシュのためにあるのかな。という理解
更に進めてSQLも廃止してISAM直接アクセスするコード出力すれば。
もうアセンブラを…という意見もすでにあるし、なんならバイナリ直接すら可能かもしれないが、もし「もうレビューしなくてよくね？」という段階になったらどこまでいくんだろう。
結局、各プロジェクト事に独自ORMみたいなものが出来上がる未来しか見えない。
貧血ドメインなら不要、リッチなドメインに真にリレーショナルからのマッピングは手動じゃないと無理、AIに書かせるなら有り
DDDとCQRSとgoを経験してからORMあんまり必要ないと思うようになっちゃった
なんでプログラマーって、型安全にこだわるくせにStringとVARCHAR間を相互変換してたり、いまだにRDBMSやCOBOL用の等幅フォントにこだわっているくせに秀丸エディタをバカにしてたりするんだろ。コピペだけで仕事しすぎか。
是非は置いておいて、ORMに限らずこのライブラリ本当に必要？って見直す機会自体は今後少なからず増えてくるかもなと感じていて、そういう意味での着眼点は大切だと感じた
AI時代にORMなんて必要なんですかね？
AIにボイラープレート書かせて生SQL回帰とか一周回って原始時代に戻った感あるわ 結局、生成された大量のコードを誰が保守するんだよっていう
好きにやりゃいいじゃん。今まで使ってた人は引き続き使う。
AIを使うなら、AIにたべさせるコンテキストを減らせるので、ボイラープレートコードは少ない方が良さそう
AI時代に、もはや関数さえ必要ない。なんならfor文さえ必要ない可能性がある。オンデマンドに実行コードを行単位で生成してくれそう。
大事なのは型安全！！！！！！！！
AIが生成したSQL文をチェックするぐらいならORMコードを生成させてチェックする方が楽だと思う派
ORMで苦労するようなSQLクエリは極力避けるべきですね。クエリで何でもやろうとする人が多いけど後で破綻するかバグの温床になる / "ORMが「SQLであればできること」のすべてをカバーできない問題"
ドメインが複雑になると普通にAIもSQLとか書き損じるからな。ただ多少の冗長さを許容しても明示性が重要になってきてるとは思う
何言ってるの？🤔
弊社ではSQLを書くコード生成型のORMはうまく機能している。保守もAIがするに決まってるので、一番うまく機能すると思ったものを採用すればいい。保守を人間がやる前提で問題視する人の気持ちがわからん。
今の所は人のレビューが必須になるので、人が読みやすいという点は無視できない。 レビューする方々のレベルもまちまちなので、レビュー時にORMが担保してくれる事を気にする必要がない。というのは大きなメリット
「ORMなしでAIにDBアクセスコードを生成"させる"」ではなく「ORMなしでAIにDBアクセスコードを生成"する"」なんですね？ 日本語がろくすっぽ使えないやつの戯言なんぞ聞く耳持たんわ。正しい日本語で書き直せ
そもそもAI時代じゃなくても値の詰め替えが出来れば良くて、環境差異の吸収ができればもっと良くて、オブジェクトとのマッピングとかマイグレーション機能をつけだすと邪魔。
アクセスするSQLが数本ならいいけど、条件分岐が増えたときの影響範囲チェックはどうするのか問題は辛そう。 最近のreactにSQL書くやつとか、PHP時代に戻ってきてるわけだし。
Onlymapsの時代が来たか…（ORMだけどSQLはそのまま書いてオブジェクト変換だけするやつ）
“ORMが「SQLであればできること」のすべてをカバーできない問題は、20年以上あるORMの歴史でずっと解決してきていません。” ORMがデータアクセスの進歩を20年停滞させた側面あるよなぁ
”ORMなしでAIにDBアクセスコードを生成する”MCPで囲った方がよさそう。
似たような話でJSフレームワークは止めてVanillaJSで良くないですか？というのもある
このままORMの存在意義がわからないまま人生終わりそう・・・
AI時代以前からトランザクションスクリプトで書けるシステムならDAOで十分（逆にバリバリのドメインオブジェクトの場合もActive Recordを使う意味は薄い）。AI時代でTxスクリプトの適用範囲が広がったのかどうかは知らん。
だから、小さいプレハブ小屋を建てる技術と高層ビルを建てる技術って違うんだよ。ビジネスだとシステムはプレハブ小屋から始まって高層ビルまでスケールアップすることを求められる。プレハブ小屋建てて満足してろ。
ORM使ってるとだいたいどこかでイラつくし、ボイラープレートコードの大量生成をAI側でやってくれるなら全然アリだと思う。昨今のセキュリティ問題も鑑みると、依存ライブラリ減らせるのは大きいしね
SQLの細かい指定をしないといけないレベルのパフォーマンスが求められるんなら、AI 関係なしにORM入れないほうがいいと思う。そういうシステムじゃないならORMのリスクは全然気にならないよ。
AIのお陰でそもそも実は要らなかっった物が露呈してきて嬉しい。ORMなん使っててメリット感じた事無いわ。
半年ORMってろ
生SQL書くとしてインジェクションとか大丈夫なのかな。文字列連結でSQL生成みたいなコードをAIが出してくると面倒い気も。
不要な例が一昔前だし、昨今のRailsでのActive RecordやGoのgormからの置き換え例が無いと、そもそも生SQL書く手段を各種WAFが用意してないならそこからになる
動的型付け語はどっちでもOK、静的型付け語はDTO生成だけでも使いたい。AIにSQLで（しかも概念なんちゃってSQLでも通じる）「これをLinQで書いて」とか指示できて助かる。確かにViewごしに発行される実SQLがクソかったりと、
生sqlは複雑化しやすいからシンプルに済ませるガイドラインとしてORMがあるのでは
ORMのままで素直に作れるか、あるいはSQLを書かなければいけない状況がたくさんあるかによって違うのでな。。あとセキュリティのことも忘れないでください。。自分が思うよりSQLインジェクションをなくすのは忘れがち
マイグレーション管理とか結局オブジェクト変換は必要になるし、やるとしてもORM経由の生SQL呼び出しでSQLだけAIに作らせるぐらいならいけるかな
自分も似たようなことを思ってた。テストが増え、フレームワークは薄くなる。もっと根本的に変わるかもだけど。
役割が変わるのは確か。そもそもリッチなやつは流行りじゃない。でもリレーショナルデータベースと言語のマッピングという本質はやっぱり必要で、型システムとの統合などの機能は要るんじゃない？
〇〇を取得してでイケるなら
まだ、生SQL書かせるほどAIを信頼出来ない
不要です。複雑なsqlになる様な操作をORM でやると何かあった時に解析が辛いし、逆にシンプルなsql ならORM はいらない。結局欲しいのはサニタイザーとクエリビルダーレベルでいい。/ sqlc でsqlからコード生成してる
そもそもORMが...
こういう人ってプロダクションコードほんとに書いてるのか疑問だ。試作アプリならどっちでもそれなりに動けばいい。
コネクションプールの管理やらを再開発する（させる）のめんどくさくね？と思ったけど、純粋にマッピングするところの話なのかな
sqlmapperのmybatisは神だったわ 今はどうかしらんけど
複雑なsqlおよび、その周辺コードをレビューする気にもあんまりなれない。
SQLには型がないのがデメリット。AIはORMも得意なので、レビューしやすいORMの方がいい。複雑なJOINやUNIONは可読性を下げるので最低限にしたい
所謂ドメインモデルとかエンティティとかにするのでなくても result["id"] とかやりたくないので何かしらのタイプに勝手にうまいことやってくれるようなマッパーはいる。人が一切読まなくて済むならどうでもいいけど
AI時代の前から不要
>AIは生SQLを書くのが得意 >ORMが「SQLであればできること」のすべてをカバーできない問題 どちらもレビュー困難な汚物みたいなSQLが飛び出してくると言う共通点はある
CRUDな処理は誰が書いても大体同じというのが一番大きいと思う。そんなところにAIのコンテキストを使うのはもったいないと思う。
「AIに生成させた例示なので、構文が誤っている可能性はあります」同じようにSQLが誤ってる可能性は考えないのかな。それならもういっそ機械語を生成させれば
出たコードを本番品質で出せるならなんでもいい
複雑性をどこに持ってくるか。そもそもORMは使ってないけど。
ORMが不要説は一部わかるけど、AI時代を引き合いにそれを主張するのは微妙な気がする。ORMを挟むことで発生する問題の多くもAIによって緩和されるようになってるんだから、むしろORMを使うほうが良いとも言えそう。
以前に他言語バインディング生成について似たようなことを考えたが、やはり後方互換性を維持できる程度に再現性が無ければ安心して使えない。stableほげほげの類が必要。
生クエリじゃないとパフォチュー出来ないからそういう意味ではわかるけど、かといって全部パフォチュー必須でもないからそういうとこではORMで良い
先日きしだ氏の「AIがバイナリを直接吐くようにはならない」という記事があったが、SQLはバイナリほど低レイヤではないが、ドメイン知識を表すには不適なので、人間が読むにもAIにドメイン知識を伝えるにもORMは必要
今後は仕様や定義ドキュメントとしての側面が強くなるんじゃない？外部制約なしのリレーションや、複数のDBを跨いで結合する時は、モデル定義した後はよしなにして欲しい時もあるから。
どういうタイミングの未来かわからんけど、途中にはレビューしないといけないタイミングがあって、 ライブラリは一定の信頼ができる可能性がある。キャッシュのためにあるのかな。という理解
更に進めてSQLも廃止してISAM直接アクセスするコード出力すれば。
もうアセンブラを…という意見もすでにあるし、なんならバイナリ直接すら可能かもしれないが、もし「もうレビューしなくてよくね？」という段階になったらどこまでいくんだろう。
結局、各プロジェクト事に独自ORMみたいなものが出来上がる未来しか見えない。
貧血ドメインなら不要、リッチなドメインに真にリレーショナルからのマッピングは手動じゃないと無理、AIに書かせるなら有り
DDDとCQRSとgoを経験してからORMあんまり必要ないと思うようになっちゃった
なんでプログラマーって、型安全にこだわるくせにStringとVARCHAR間を相互変換してたり、いまだにRDBMSやCOBOL用の等幅フォントにこだわっているくせに秀丸エディタをバカにしてたりするんだろ。コピペだけで仕事しすぎか。
是非は置いておいて、ORMに限らずこのライブラリ本当に必要？って見直す機会自体は今後少なからず増えてくるかもなと感じていて、そういう意味での着眼点は大切だと感じた