ORM と向き合う

DBが高機能になって、ORMではその機能を使うために結局生SQLを挟むような状態になってくると、ORMの存在がむしろ邪魔だよとなるので、遅かれ早かれ生SQLに行き着くとは常々思う。ユーザもサービスの多機能化を望むし

「N+1問題」はORMユーザーの無知が引き起こすただのバグなので、数学の未解決問題のような大袈裟な名前を持って来て論じるふりして結局言い訳にしかならないのは非常にダサい。

長期的には多数の言語とフレームワーク使うことになるので、ORMよりSQL(とデータベース)の方が学習コスト低い。ORM起因のトラブルも回避しやすいし。個人的にはSQLは楽しいがORMはそれほどでないのであんまり・・・

結局複雑なことをしたいとか性能面を見ると「勝手に色々やってくれる」が怖すぎる。多機能だと学習コストもかかるしその分バグを踏む率が上がる。それで何度痛い目を見たことか...。多機能ORMには否定派。

正直N+1問題が生じるDBって欠陥品だと思う。普通に何回もクエリ投げたいだろと。DBの都合にアプリケーションが合わせなきゃいけないというのが諸悪の根源。

Prisma Python

ORMに期待する機能の分解が解像度高くて良い。私も格好いいインターフェースは別に要らない派

prisma+python いいかも

.NETを使うこと多いんだけど多機能なORMのEntityFrameworkとSQLのマッピングだけやるMicroORMのDapperを併用してるかな。単一データの更新はORMが、複雑な検索や大量の更新にはSQL(MicroORMでSQLで投げて結果をObjectでもらう)が向いてる

結局複雑なことをしたいとか性能面を見ると「勝手に色々やってくれる」が怖すぎる。多機能だと学習コストもかかるしその分バグを踏む率が上がる。それで何度痛い目を見たことか...。多機能ORMには否定派。

今や当然だけどテーブル定義渡してAIに指示すれば生SQL作ってくれますよ。ORMが作るSQLだと後でパフォーマンスが問題になってくるので生SQLと実行計画で試行錯誤しながらチューニングするのが最も安定。

SQL書くのは面倒くさいし、型安全にオブジェクトにマッピングするのはさらに面倒くさすぎる

JOINの2個目の方法は完全な生SQLだから苦行なんだよ。「値はマッピングするけど、SQLは自分で書く」くらいのちょうどいいORMであってほしい。

子集約としての関連テーブルをある程度効率よく取ってくるやつは欲しいけど、基本的にはSQL書いてるので未だよく選定の論争がわからん世界

ちょうどPrisma Pythonと戦ってる、ちょっと不便だけど

あまりガッツリは必要ないけれど、かんたんなクエリビルダーとデータマッパーぐらいは欲しいよねというのをこの頃痛感してる。

長期的には多数の言語とフレームワーク使うことになるので、ORMよりSQL(とデータベース)の方が学習コスト低い。ORM起因のトラブルも回避しやすいし。個人的にはSQLは楽しいがORMはそれほどでないのであんまり・・・

DBの方がアプリより寿命長いから、DBからクラス生成することのほうが多い気がする。基本EF使ってて、キー無しテーブルにインサートしたいとかAOTビルドしたい場合にDapper使うのが良いのかなって思ってる。

SQLを元にクライアントコードを生成する流れに落ち着くことを願う

N+1を発生させてるのは大抵の場合フレームワーク側であってdb側ではないと思うのだが・・・

DBFluteでずっと困ってない。

DBが高機能になって、ORMではその機能を使うために結局生SQLを挟むような状態になってくると、ORMの存在がむしろ邪魔だよとなるので、遅かれ早かれ生SQLに行き着くとは常々思う。ユーザもサービスの多機能化を望むし

.NETのEntity Frameworkのパワフルさが逆に分かる。

正直N+1問題が生じるDBって欠陥品だと思う。普通に何回もクエリ投げたいだろと。DBの都合にアプリケーションが合わせなきゃいけないというのが諸悪の根源。

prismaで独自フォーマット追加になってまた（ｒｙ

まだ向き合ってんのかよ。何十年向き合い続けてんだよ / コネクションプーリングやトランザクションなんてORM関係ないだろ。そのORMの設計が悪いだけで。

アプリとDBでテーブル定義を二重保持するのは確かに嫌だけど、実際の開発時は「既存のアプリのDB」も見ることが非常に多いので、「向きはどちらでもいい」わけがない。

「N+1問題」はORMユーザーの無知が引き起こすただのバグなので、数学の未解決問題のような大袈裟な名前を持って来て論じるふりして結局言い訳にしかならないのは非常にダサい。

prismaってpythonで使えるんだー