プログラマの雑談部屋 ★376 (241ﾚｽ)
上下前次1-新
152(1): 11/16(日)00:05 AAS
長いけどチャッピーに聞いたらこう答えたんだけどどう思う？
ormを使わず生sqlだけでデータベース接続をする場合、どれくらいのテーブル数が適していますか
ChatGPT:
結論から言うと 「生SQLだけで運用できるテーブル数には明確な上限はない」 ですが、
実務的には 50〜150 テーブルが限界ラインになり、200〜300 を超えると生SQLだけは非推奨 になります。
その理由と基準を詳しく説明します。
153(1): 11/16(日)00:05 AAS
✅ 結論：生SQLだけでの運用に適したテーブル数の目安
■ 〜50テーブル
生SQLだけで十分運用可能
構造も把握しやすい
スキーマ変更時の影響範囲も小さい
■ 50〜150テーブル
チームと設計次第では生SQLのみでも運用できる
ただし クエリがスパゲッティ化し始めるゾーン
接続管理・トランザクション管理は手厚くする必要あり
■ 150〜300テーブル
生SQLだけだとかなりつらくなる
スキーマ変更時のクエリ修正の影響範囲が爆発する
どこで何のSQLが使われてるか管理しきれなくなる
→ ORMまたはQuery Builderを部分的に併用すべき
■ 300テーブル以上
生SQLだけはほぼ不可能
保守・修正コストが異常に高くなる
「どのSQLがどのテーブルに影響しているか」が分からなくなる
→ ORMまたは型付きRepository層が必須
154(1): 11/16(日)00:06 AAS
🔥 生SQLだけで運用すると破綻する理由
1. スキーマ変更の影響範囲が手作業で対応しきれない
例：カラム名1つ変えるだけで数百ファイルに影響する可能性。
ORMならモデル1箇所を直せばよいが、生SQLでは全部探す必要がある。
2. SQLがどこで使われているかコード上から追えない
生SQLは散らばりやすい
grep 検索では限界がある
依存関係管理ができない
3. 型・補完などIDEの恩恵が受けにくい
コード補完が効かないため、ミスが多発する。
4. 複数人開発でバラバラのSQLが生まれる
JOINの仕方が人によって違う
N+1問題も起きやすい
共通化が難しい
5. テーブル数が増えるほどリファクタリング不能になる
300テーブルを生SQLで100%管理するのはほぼ無理。
155: 11/16(日)00:07 AAS
🔧 実務では何が起きるか？
100テーブル → 「なんとかなる」
SQLが複雑になっても人間が把握できる
200テーブル → 「構造管理が苦しくなる」
影響範囲調査が辛い
スキーマ変更のたびに改修数が膨れ上がる
300テーブル以上 → 「保守不能に近い」
統一ルールなしだと破滅
SQLの共通化や自動生成が必須レベル
🎯 最適解（生SQL中心で行きたい場合）
生SQLを使いたいなら、以下の組み合わせが最強です：
RepositoryパターンでSQLを一箇所に集約
SQLテンプレートを作る（共通化）
Query Builderを併用（完全ORMは使わない）
型定義（TypeScript・Pydanticなど）をDBと同期
これらを入れれば 150〜200テーブルでも生SQL中心で耐えられる。
156: 11/16(日)00:07 AAS
✅ 最終結論
「生SQLだけ」でやりやすいテーブル数の目安は 〜100
150〜200でギリギリ、300以上は非推奨
ただし以下によって変わります：
チーム全員がSQLに強いか？
スキーマ変更が頻繁か？
分析系か、トランザクション系か？
Query Builder を併用するか？
157: 11/16(日)00:16 AAS
>>152
～50テーブルでも可能なだけでおすすめしないところがSQLの限界を感じるな
ORMは色んな理由で使用推奨やからそこは議論の余地はないと思ってる
158: 11/16(日)00:29 AAS
5000超えも普通にあるだろ
200くらいが丁度いい
それって貴方の感想ですよね
159: 11/16(日)00:55 AAS
テーブル数が300を超えていたら
その現場から逃げよう
160: 11/16(日)01:22 AAS
>>153
自分の使っているフレームワークだとEntityとペアになったRepositoryクラスにORMを使って絞り込みとかの機能を持たせたメソッドを書くのが基本になってるな
161: 11/16(日)01:26 AAS
>>154
ORM使っていても気をつけないとN+1問題は起きる。最近、人が書いたコードを修正したんだけど、参照しているエンティティを遅延ロードしていたおかげでクエリ数が爆発してた。
162(1): 11/16(日)01:26 AAS
機能境界とかでちゃんとDB分けたりネームスペース設定せい
163: 11/16(日)01:26 AAS
深夜の背徳トリプルチーズバーガー
164: 11/16(日)01:31 AAS
>>162
自分の使っているフレームワークとORMだと複数DBを使える可能性もあるようだけど、なんか面倒なことが起こりそうで誰も手を出さないわ。そもそも複雑に絡み合いすぎていて機能境界なんてないと思う
165: 11/16(日)01:33 AAS
マイクロサービス化は？
166: 11/16(日)03:21 AAS
MITからChatGPT活用頻度の高い人の脳活性が低いって研究が出た
167: 11/16(日)07:09 AAS
DB分けたので大失敗した
168(1): 11/16(日)08:15 AAS
あたまがぼんやりしてうごかない
169: 11/16(日)08:22 AAS
>>168
もう引退しなよ。周りに負担がかかりすぎてる
170: 11/16(日)08:29 AAS
彡 ⌒ ミ
(´・ω・`) ぼんやり見えてこないか眺めてる
171: 11/16(日)08:33 AAS
本の誤記を連絡するページに飛んだらメールアドレス必須だったからやめた
誰も計算なんか真面目にやらないだろうからずーっと間違えたままなんだろうな
172: 11/16(日)08:38 AAS
捏造メアドでも届くは届くだろ
173: 11/16(日)08:44 AAS
おっぱい
174: 11/16(日)08:57 AAS
本の誤記に気がつく者だけが真実に辿り着く
もうそれでいいじゃないか
本を鵜呑みにして一生悩んでろだよ
そもそも正誤表を調べようなんて人も一握りだし
175: 11/16(日)10:39 AAS
ねむたいから寝る
頭もぼけてるし
もうしぬんじゃないかといつもおもう
176: 11/16(日)10:40 AAS
前頭葉にダメージを負った人間の行動がおれにそっくりだった
177: 11/16(日)11:14 AAS
顔認証のロック解除って、その人の実物大の顔写真があればできますか？
178: 11/16(日)11:53 AAS
そんなものなくてもAIで生成した画像があればできるよ
179: 11/16(日)12:01 AAS
お前らDBで例えばユーザ管理すりテーブル作るとするやん
社員番号なのか何なのか一意キーとして列作るなら
id
user_id
どっち使う？
180: 11/16(日)12:04 AAS
user_id
181: 11/16(日)12:04 AAS
idはサロゲートキーにしか使ってねえや
上下前次1-新書関写板覧索設栞歴
あと 60 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.015s