プログラマの雑談部屋 ★376 (166ﾚｽ)
プログラマの雑談部屋 ★376 http://medaka.5ch.net/test/read.cgi/prog/1762945137/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
149: 仕様書無しさん [sage] 2025/11/15(土) 23:50:53.38 >>147 書かない つうか最近のDBツールだとER図みたいな画面持ってるやん なんで書くのよ http://medaka.5ch.net/test/read.cgi/prog/1762945137/149
150: 仕様書無しさん [] 2025/11/16(日) 00:00:10.69 >>149 設計段階でまずどんなん作るか決めなあかんやん そこもDBツールで書いちゃうの？ http://medaka.5ch.net/test/read.cgi/prog/1762945137/150
151: 仕様書無しさん [sage] 2025/11/16(日) 00:01:08.24 テーブルは適度に非正規化しないとパフォーマンス落ちるやろ http://medaka.5ch.net/test/read.cgi/prog/1762945137/151
152: 仕様書無しさん [sage] 2025/11/16(日) 00:05:21.69 長いけどチャッピーに聞いたらこう答えたんだけどどう思う？ ormを使わず生sqlだけでデータベース接続をする場合、どれくらいのテーブル数が適していますか ChatGPT: 結論から言うと 「生SQLだけで運用できるテーブル数には明確な上限はない」 ですが、 実務的には 50〜150 テーブルが限界ラインになり、200〜300 を超えると生SQLだけは非推奨 になります。 その理由と基準を詳しく説明します。 http://medaka.5ch.net/test/read.cgi/prog/1762945137/152
153: 仕様書無しさん [sage] 2025/11/16(日) 00:05:49.15 ✅ 結論：生SQLだけでの運用に適したテーブル数の目安 ■ 〜50テーブル 生SQLだけで十分運用可能 構造も把握しやすい スキーマ変更時の影響範囲も小さい ■ 50〜150テーブル チームと設計次第では生SQLのみでも運用できる ただし クエリがスパゲッティ化し始めるゾーン 接続管理・トランザクション管理は手厚くする必要あり ■ 150〜300テーブル 生SQLだけだとかなりつらくなる スキーマ変更時のクエリ修正の影響範囲が爆発する どこで何のSQLが使われてるか管理しきれなくなる → ORMまたはQuery Builderを部分的に併用すべき ■ 300テーブル以上 生SQLだけはほぼ不可能 保守・修正コストが異常に高くなる 「どのSQLがどのテーブルに影響しているか」が分からなくなる → ORMまたは型付きRepository層が必須 http://medaka.5ch.net/test/read.cgi/prog/1762945137/153
154: 仕様書無しさん [sage] 2025/11/16(日) 00:06:20.23 🔥 生SQLだけで運用すると破綻する理由 1. スキーマ変更の影響範囲が手作業で対応しきれない 例：カラム名1つ変えるだけで数百ファイルに影響する可能性。 ORMならモデル1箇所を直せばよいが、生SQLでは全部探す必要がある。 2. SQLがどこで使われているかコード上から追えない 生SQLは散らばりやすい grep 検索では限界がある 依存関係管理ができない 3. 型・補完などIDEの恩恵が受けにくい コード補完が効かないため、ミスが多発する。 4. 複数人開発でバラバラのSQLが生まれる JOINの仕方が人によって違う N+1問題も起きやすい 共通化が難しい 5. テーブル数が増えるほどリファクタリング不能になる 300テーブルを生SQLで100%管理するのはほぼ無理。 http://medaka.5ch.net/test/read.cgi/prog/1762945137/154
155: 仕様書無しさん [sage] 2025/11/16(日) 00:07:10.27 🔧 実務では何が起きるか？ 100テーブル → 「なんとかなる」 SQLが複雑になっても人間が把握できる 200テーブル → 「構造管理が苦しくなる」 影響範囲調査が辛い スキーマ変更のたびに改修数が膨れ上がる 300テーブル以上 → 「保守不能に近い」 統一ルールなしだと破滅 SQLの共通化や自動生成が必須レベル 🎯 最適解（生SQL中心で行きたい場合） 生SQLを使いたいなら、以下の組み合わせが最強です： RepositoryパターンでSQLを一箇所に集約 SQLテンプレートを作る（共通化） Query Builderを併用（完全ORMは使わない） 型定義（TypeScript・Pydanticなど）をDBと同期 これらを入れれば 150〜200テーブルでも生SQL中心で耐えられる。 http://medaka.5ch.net/test/read.cgi/prog/1762945137/155
156: 仕様書無しさん [sage] 2025/11/16(日) 00:07:20.83 ✅ 最終結論 「生SQLだけ」でやりやすいテーブル数の目安は 〜100 150〜200でギリギリ、300以上は非推奨 ただし以下によって変わります： チーム全員がSQLに強いか？ スキーマ変更が頻繁か？ 分析系か、トランザクション系か？ Query Builder を併用するか？ http://medaka.5ch.net/test/read.cgi/prog/1762945137/156
157: 仕様書無しさん [] 2025/11/16(日) 00:16:21.28 >>152 ～50テーブルでも可能なだけでおすすめしないところがSQLの限界を感じるな ORMは色んな理由で使用推奨やからそこは議論の余地はないと思ってる http://medaka.5ch.net/test/read.cgi/prog/1762945137/157
158: 仕様書無しさん [sage] 2025/11/16(日) 00:29:29.27 5000超えも普通にあるだろ 200くらいが丁度いい それって貴方の感想ですよね http://medaka.5ch.net/test/read.cgi/prog/1762945137/158
159: 仕様書無しさん [sage] 2025/11/16(日) 00:55:05.72 テーブル数が300を超えていたら その現場から逃げよう http://medaka.5ch.net/test/read.cgi/prog/1762945137/159
160: 仕様書無しさん [] 2025/11/16(日) 01:22:46.92 >>153 自分の使っているフレームワークだとEntityとペアになったRepositoryクラスにORMを使って絞り込みとかの機能を持たせたメソッドを書くのが基本になってるな http://medaka.5ch.net/test/read.cgi/prog/1762945137/160
161: 仕様書無しさん [] 2025/11/16(日) 01:26:04.73 >>154 ORM使っていても気をつけないとN+1問題は起きる。最近、人が書いたコードを修正したんだけど、参照しているエンティティを遅延ロードしていたおかげでクエリ数が爆発してた。 http://medaka.5ch.net/test/read.cgi/prog/1762945137/161
162: 仕様書無しさん [sage] 2025/11/16(日) 01:26:07.52 機能境界とかでちゃんとDB分けたりネームスペース設定せい http://medaka.5ch.net/test/read.cgi/prog/1762945137/162
163: 仕様書無しさん [sage] 2025/11/16(日) 01:26:36.43 深夜の背徳トリプルチーズバーガー http://medaka.5ch.net/test/read.cgi/prog/1762945137/163
164: 仕様書無しさん [] 2025/11/16(日) 01:31:01.61 >>162 自分の使っているフレームワークとORMだと複数DBを使える可能性もあるようだけど、なんか面倒なことが起こりそうで誰も手を出さないわ。そもそも複雑に絡み合いすぎていて機能境界なんてないと思う http://medaka.5ch.net/test/read.cgi/prog/1762945137/164
165: 仕様書無しさん [] 2025/11/16(日) 01:33:44.88 マイクロサービス化は？ http://medaka.5ch.net/test/read.cgi/prog/1762945137/165
166: 仕様書無しさん [sage] 2025/11/16(日) 03:21:10.50 MITからChatGPT活用頻度の高い人の脳活性が低いって研究が出た http://medaka.5ch.net/test/read.cgi/prog/1762945137/166
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.006s