AI時代にORMなんて必要なんですかね？

新規で構築するシステムの設計を考えていて、 「今の時代にORMなんているんか？？？」 という思いに至ったので、これを書いてます。 ORMなしでAIにDBアクセスコードを生成する AIでコードを生成する前提として、 AIは生SQLを書くのが得意 オブジェクトマッピングみたいなボイラープレートをAIに生成させるコストは極小（人間が手で書くとめちゃくちゃ時間がかかる） という点が挙げられます。 そのため、AIを使う前提であれば、ORMなしで以下の作業を行っても、必要なコスト（特に時間）は極小です。 ドメイン要件を伝えてSQLを生成させる オブジェクトマッピング処理（いわゆるDAO）を生成させる 単体テストコードを生成させる というか、ドメインロジックを書いていく過程で上記のようなDBアクセスコードを、都度必要となった分だけ生成させていくのであれば、この部分の生成に時間がかかってると認識することは

[bellonieta]

AIが生成したSQL文をチェックするぐらいならORMコードを生成させてチェックする方が楽だと思う派

[prograti]

ORMで苦労するようなSQLクエリは極力避けるべきですね。クエリで何でもやろうとする人が多いけど後で破綻するかバグの温床になる / "ORMが「SQLであればできること」のすべてをカバーできない問題"

[takeag]

今の所は人のレビューが必須になるので、人が読みやすいという点は無視できない。 レビューする方々のレベルもまちまちなので、レビュー時にORMが担保してくれる事を気にする必要がない。というのは大きなメリット

[queeuq]

こういう人ってプロダクションコードほんとに書いてるのか疑問だ。試作アプリならどっちでもそれなりに動けばいい。

[mole-studio]

ドメインが複雑になると普通にAIもSQLとか書き損じるからな。ただ多少の冗長さを許容しても明示性が重要になってきてるとは思う

[abstruct3431]

「ORMなしでAIにDBアクセスコードを生成"させる"」ではなく「ORMなしでAIにDBアクセスコードを生成"する"」なんですね？　　日本語がろくすっぽ使えないやつの戯言なんぞ聞く耳持たんわ。正しい日本語で書き直せ

[manimoto]

先日きしだ氏の「AIがバイナリを直接吐くようにはならない」という記事があったが、SQLはバイナリほど低レイヤではないが、ドメイン知識を表すには不適なので、人間が読むにもAIにドメイン知識を伝えるにもORMは必要

[crexist]

不要です。複雑なsqlになる様な操作をORM でやると何かあった時に解析が辛いし、逆にシンプルなsql ならORM はいらない。結局欲しいのはサニタイザーとクエリビルダーレベルでいい。/ sqlc でsqlからコード生成してる

[tfurukaw]

このままORMの存在意義がわからないまま人生終わりそう・・・

[toro-chan]

ORMのままで素直に作れるか、あるいはSQLを書かなければいけない状況がたくさんあるかによって違うのでな。。あとセキュリティのことも忘れないでください。。自分が思うよりSQLインジェクションをなくすのは忘れがち

[misshiki]

AIが生SQL生成やDAO/DTO（マッピング）生成、単体テスト生成までやれるなら、ORMの本来の旨味（ボイラープレート削減）が薄いという問題提起。

[deep_one]

SQLを直接書かせると安全性が低くなる。

[rawwell]

SQLインジェクションのリスクがあるSQLをただの一度も書いたことのない人だけが石を投げなさい

[paulownia]

意見としては根拠が弱いかな。ORMを使う弊害に挙げられているオーバーヘッドは微々たるものだし、それ以外はそれこそAIが解決してくれるものだし

[kobito19]

ORMつってもやってることピンキリなんで具体的なプロダクト名で語ろうよ。例に出てるHibernateとiBATISでも全然違うやろ(S2Daoは知らん)。Hibernateをその理解で使っているのだとしたらORMのこと何もわかってない

[devgai]

メリットはクロスプラットフォームくらいかな sqliteからpostgresqlに切り替えますとか ORM使おうが使わまいがコード量も変わらないしAI時代はAIが得意なものが伸びるだろう

[Magicant]

sqlx みたいな DB フロントエンドがあれば十分で ORM は要らんとは俺も思ふ

[kazokmr]

DAOをどうするかだと思う。テストは変わらず書くしSQLでレビューした方が良いしORM使う必要性は薄くなった。コネクション取得やインジェクション気にするのは面倒だからそれはライブラリ使うけどそれORMじゃんみたいな？

[klbym]

もうちょっと複数観点見てから決めてもいい気がするかな。セキュリティ面の考慮を減らせたり、ランタイム時のエラーを減らせたり(ビルド時の型安全保証)、domaみたいに2-way(生のsql書くタイプのorm)もあったりするし

[benibana2001abc]

是非は置いておいて、ORMに限らずこのライブラリ本当に必要？って見直す機会自体は今後少なからず増えてくるかもなと感じていて、そういう意味での着眼点は大切だと感じた

[pmint]

反発したくなるのはコピペプログラマーだから。新技術が分からない。型安全にこだわるくせにStringとVARCHARを相互変換したり、いまだにRDBMSやCOBOL用の等幅フォントにこだわっているくせに秀丸エディタをバカにしたり。

[peketamin]

DDDとCQRSとgoを経験してからORMあんまり必要ないと思うようになっちゃった/いくつもテーブルが関係して結合条件も複雑になる場合、ORMが吐くSQLのスロークエリ確認して結局SQLを見ることになるし

[syuu256]

貧血ドメインなら不要、リッチなドメインに真にリレーショナルからのマッピングは手動じゃないと無理、AIに書かせるなら有り

[syu-m-5151]

結局、各プロジェクト事に独自ORMみたいなものが出来上がる未来しか見えない。

[cu39]

もうアセンブラを…という意見もすでにあるし、なんならバイナリ直接すら可能かもしれないが、もし「もうレビューしなくてよくね？」という段階になったらどこまでいくんだろう。

[xsde]

更に進めてSQLも廃止してISAM直接アクセスするコード出力すれば。

[clairvy]

どういうタイミングの未来かわからんけど、途中にはレビューしないといけないタイミングがあって、 ライブラリは一定の信頼ができる可能性がある。キャッシュのためにあるのかな。という理解

[sametashark]

今後は仕様や定義ドキュメントとしての側面が強くなるんじゃない？外部制約なしのリレーションや、複数のDBを跨いで結合する時は、モデル定義した後はよしなにして欲しい時もあるから。

[tonza_dopeness]

生クエリじゃないとパフォチュー出来ないからそういう意味ではわかるけど、かといって全部パフォチュー必須でもないからそういうとこではORMで良い

[atsushieno]

以前に他言語バインディング生成について似たようなことを考えたが、やはり後方互換性を維持できる程度に再現性が無ければ安心して使えない。stableほげほげの類が必要。

[shingo-sasaki-0529]

ORMが不要説は一部わかるけど、AI時代を引き合いにそれを主張するのは微妙な気がする。ORMを挟むことで発生する問題の多くもAIによって緩和されるようになってるんだから、むしろORMを使うほうが良いとも言えそう。

[taguch1]

複雑性をどこに持ってくるか。そもそもORMは使ってないけど。

[naka-06_18]

出たコードを本番品質で出せるならなんでもいい

[tokuniimihanai]

「AIに生成させた例示なので、構文が誤っている可能性はあります」同じようにSQLが誤ってる可能性は考えないのかな。それならもういっそ機械語を生成させれば

[rryu]

CRUDな処理は誰が書いても大体同じというのが一番大きいと思う。そんなところにAIのコンテキストを使うのはもったいないと思う。

[hiby]

>AIは生SQLを書くのが得意　>ORMが「SQLであればできること」のすべてをカバーできない問題　どちらもレビュー困難な汚物みたいなSQLが飛び出してくると言う共通点はある

[Shinwiki]

AI時代の前から不要

[ghostbass]

所謂ドメインモデルとかエンティティとかにするのでなくても result["id"] とかやりたくないので何かしらのタイプに勝手にうまいことやってくれるようなマッパーはいる。人が一切読まなくて済むならどうでもいいけど

[gami]

SQLには型がないのがデメリット。AIはORMも得意なので、レビューしやすいORMの方がいい。複雑なJOINやUNIONは可読性を下げるので最低限にしたい