プログラマの雑談部屋 ★376

**仕様書無しさん** · 2025/11/12(水) 19:58:57.82

雑談スレ

前スレ
プログラマの雑談部屋 ★375
https://itest.5ch.net/medaka/test/read.cgi/prog/1761686679

**仕様書無しさん** · 2025/11/15(土) 22:43:40.69

今はAIが全てのベストプラクティスをご存知なのでまだいい
当時はひとつひとつが鬼門だった
いや今でもサボったほうが楽なことが多くて後々地獄になる
簡単そうには見えるんだが
個々のSQLの膨らみ具合と
こんなはずじゃない勢いのテーブル増加を見て怖気づく

**仕様書無しさん** · 2025/11/15(土) 22:48:21.17

>>128
まさにその状態の真っ只中にいる。とにかく責任者が思いついたらその機能を2-3日みたいなスパンで投入しないといけないのでじっくり設計とかしている暇はない。いまこれリリースしたらトラブル可能性ありますよと言ってもとにかく機能が欲しい、トラブっても動かしながら直せばいいみたいな感じ

まぁ結論としてはまともなエンジニアリングをしている会社で働こう！ということだなw

**仕様書無しさん** · 2025/11/15(土) 22:51:46.60

うそです会社で設計したことない
ジジイなので記憶が改竄されてた

**仕様書無しさん** · 2025/11/15(土) 22:52:00.47

>>131
テーブルやSQLが複雑になってももう気にしなくてもよいのでは？自分で書く時代は終わってAIに任せておけば複雑なSQLも一瞬で仕上げてくれるんだし。必死で勉強して大量にSQL書いてきたけど、まったくもってAIの書くスピードとSQLの内容のスマートさにはかなわんわ

**仕様書無しさん** · 2025/11/15(土) 22:54:25.35

ああそっか…
時代はかわったんだ…

**仕様書無しさん** · 2025/11/15(土) 22:55:40.21

下剤効いて2kg出た

**仕様書無しさん** · 2025/11/15(土) 22:57:31.70

なにもさせてもらえなかった
社会に影響を与えるチャンスは
ことごとく足払いをかけられて潰されてきた

**仕様書無しさん** · 2025/11/15(土) 22:58:56.11

>>132
まともなエンジニアリングしてる大手有名会社がそういう事してるからだよ

MSとかAppleとかAWSとかGoogleとかMetaとかその他諸々

**仕様書無しさん** · 2025/11/15(土) 22:59:28.05

自分の状況は悪くはない
悪くはないが結局は社会に消されたんだ

**仕様書無しさん** · 2025/11/15(土) 23:00:20.40

>>129
>時間によってバージョン切り替え

バージョンによって、じゃなくてマスタ切り替えではなくて？

>開始時間と終了時間の両方をカラム

判然とせんけどたぶんイエス

>ビューを付けたほうがいいでしょうか？

サービスによる

>リカーシブな読み込み前提のテーブルを作ってもいいでしょうか？

おつしるとおり軽々に取り入れるのではなく、運用上アンチパターン化することはないか設計時点で考えるべき

>レコードの版をどうやって管理しますか？

バージョンカラム？
危惧されている結合における面倒ごととは？

>論理削除使いますか？
>削除した情報を見たいなんて要求がある

このユースケース、要望なら当然論理
物理、保持期間は要件次第

**仕様書無しさん** · 2025/11/15(土) 23:02:38.39

>>140
標準的な人間の回答をありがとう
見通しが立たなくてわからんから聞いてるんだが結局人間じゃこういう回答が返ってくるよな
当然だ

AIなら

**仕様書無しさん** · 2025/11/15(土) 23:33:11.05

テーブル数多くなってきたらGUIかORM使うのが普通になってくるってこと？
CLIとか素のSQL文の管理とかできる気がしないんだけど

**仕様書無しさん** · 2025/11/15(土) 23:33:40.02

テーブル数多い時にね

**仕様書無しさん** · 2025/11/15(土) 23:36:16.42

GUIかORMて

**仕様書無しさん** · 2025/11/15(土) 23:38:29.74

納豆パン作ってみたらめちゃくちゃまずかった
大豆はまだ食えたんだが

**仕様書無しさん** · 2025/11/15(土) 23:40:05.32

お前らみたいに有能なプログラマーになりたいのでご教授くださいやがれ

**仕様書無しさん** · 2025/11/15(土) 23:40:23.36

ORMあっても簡単なER図書かない？

**仕様書無しさん** · 2025/11/15(土) 23:46:30.49

うんこが便器から飛び出しているかテストするときに
・うんこが完全に便器の中にある
・うんこが半分飛び出している
・うんこが完全に飛び出している
・うんこが便器をまたいで飛び出している
の境界テストをすればいいだけなのだが

センスのない奴にテスト仕様を書かせると
・うんこがちょっとだけ飛び出している
・うんこがなんとなく飛び出している
・うんこがすごく飛び出している
・うんこが隣の便器に飛び出している
などと、同じロジックを通るテストケースを大量に作り出す

**仕様書無しさん** · 2025/11/15(土) 23:50:53.38

>>147
書かない

つうか最近のDBツールだとER図みたいな画面持ってるやん
なんで書くのよ

**仕様書無しさん** · 2025/11/16(日) 00:00:10.69

>>149
設計段階でまずどんなん作るか決めなあかんやん
そこもDBツールで書いちゃうの？

**仕様書無しさん** · 2025/11/16(日) 00:01:08.24

テーブルは適度に非正規化しないとパフォーマンス落ちるやろ

**仕様書無しさん** · 2025/11/16(日) 00:05:21.69

長いけどチャッピーに聞いたらこう答えたんだけどどう思う？

ormを使わず生sqlだけでデータベース接続をする場合、どれくらいのテーブル数が適していますか
ChatGPT:
結論から言うと「生SQLだけで運用できるテーブル数には明確な上限はない」ですが、
実務的には 50～150 テーブルが限界ラインになり、200～300 を超えると生SQLだけは非推奨になります。
その理由と基準を詳しく説明します。

**仕様書無しさん** · 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層が必須

**仕様書無しさん** · 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%管理するのはほぼ無理。

**仕様書無しさん** · 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中心で耐えられる。

**仕様書無しさん** · 2025/11/16(日) 00:07:20.83

✅ 最終結論
「生SQLだけ」でやりやすいテーブル数の目安は～100
150～200でギリギリ、300以上は非推奨
ただし以下によって変わります：
チーム全員がSQLに強いか？

スキーマ変更が頻繁か？

分析系か、トランザクション系か？

Query Builder を併用するか？

**仕様書無しさん** · 2025/11/16(日) 00:16:21.28

>>152
～50テーブルでも可能なだけでおすすめしないところがSQLの限界を感じるな
ORMは色んな理由で使用推奨やからそこは議論の余地はないと思ってる

**仕様書無しさん** · 2025/11/16(日) 00:29:29.27

5000超えも普通にあるだろ
200くらいが丁度いい
それって貴方の感想ですよね

**仕様書無しさん** · 2025/11/16(日) 00:55:05.72

テーブル数が300を超えていたら
その現場から逃げよう

**仕様書無しさん** · 2025/11/16(日) 01:22:46.92

>>153
自分の使っているフレームワークだとEntityとペアになったRepositoryクラスにORMを使って絞り込みとかの機能を持たせたメソッドを書くのが基本になってるな

**仕様書無しさん** · 2025/11/16(日) 01:26:04.73

>>154
ORM使っていても気をつけないとN+1問題は起きる。最近、人が書いたコードを修正したんだけど、参照しているエンティティを遅延ロードしていたおかげでクエリ数が爆発してた。

**仕様書無しさん** · 2025/11/16(日) 01:26:07.52

機能境界とかでちゃんとDB分けたりネームスペース設定せい

**仕様書無しさん** · 2025/11/16(日) 01:26:36.43

深夜の背徳トリプルチーズバーガー

**仕様書無しさん** · 2025/11/16(日) 01:31:01.61

>>162
自分の使っているフレームワークとORMだと複数DBを使える可能性もあるようだけど、なんか面倒なことが起こりそうで誰も手を出さないわ。そもそも複雑に絡み合いすぎていて機能境界なんてないと思う

**仕様書無しさん** · 2025/11/16(日) 01:33:44.88

マイクロサービス化は？

**仕様書無しさん** · 2025/11/16(日) 03:21:10.50

MITからChatGPT活用頻度の高い人の脳活性が低いって研究が出た

**仕様書無しさん** · 2025/11/16(日) 07:09:25.48

DB分けたので大失敗した

**仕様書無しさん** · 2025/11/16(日) 08:15:36.48

あたまがぼんやりしてうごかない

**仕様書無しさん** · 2025/11/16(日) 08:22:39.70

>>168
もう引退しなよ。周りに負担がかかりすぎてる

**仕様書無しさん** · 2025/11/16(日) 08:29:51.77

彡 ⌒ ミ
(´・ω・`) ぼんやり見えてこないか眺めてる

**仕様書無しさん** · 2025/11/16(日) 08:33:42.05

本の誤記を連絡するページに飛んだらメールアドレス必須だったからやめた
誰も計算なんか真面目にやらないだろうからずーっと間違えたままなんだろうな

**仕様書無しさん** · 2025/11/16(日) 08:38:00.20

捏造メアドでも届くは届くだろ

**仕様書無しさん** · 2025/11/16(日) 08:44:45.36

おっぱい

**仕様書無しさん** · 2025/11/16(日) 08:57:47.94

本の誤記に気がつく者だけが真実に辿り着く
もうそれでいいじゃないか
本を鵜呑みにして一生悩んでろだよ
そもそも正誤表を調べようなんて人も一握りだし

**仕様書無しさん** · 2025/11/16(日) 10:39:05.17

ねむたいから寝る
頭もぼけてるし
もうしぬんじゃないかといつもおもう

**仕様書無しさん** · 2025/11/16(日) 10:40:35.33

前頭葉にダメージを負った人間の行動がおれにそっくりだった

**仕様書無しさん** · 2025/11/16(日) 11:14:10.60

顔認証のロック解除って、その人の実物大の顔写真があればできますか？

**仕様書無しさん** · 2025/11/16(日) 11:53:53.83

そんなものなくてもAIで生成した画像があればできるよ

**仕様書無しさん** · 2025/11/16(日) 12:01:44.76

お前らDBで例えばユーザ管理すりテーブル作るとするやん
社員番号なのか何なのか一意キーとして列作るなら

id
user_id

どっち使う？

**仕様書無しさん** · 2025/11/16(日) 12:04:29.92

user_id

**仕様書無しさん** · 2025/11/16(日) 12:04:39.49

idはサロゲートキーにしか使ってねえや

**仕様書無しさん** · 2025/11/16(日) 12:06:29.80

社員番号のような何かはuser_idに入れる。
idはレコードそのものユニークIDを入れる列名として定着してるから、そこに社員番号を入れるのはもはや嫌がらせに近い。

**仕様書無しさん** · 2025/11/16(日) 12:08:28.96

userテーブルの主キーはidだろ
テーブル名がuserだからuser_idは冗長だわ
外部キーとして使う時はuser_idだけど

**仕様書無しさん** · 2025/11/16(日) 12:09:42.50

そんなことより、ユーザ管理すりテーブル
が何なのか気になるわ

**仕様書無しさん** · 2025/11/16(日) 12:10:11.32

やめておけ
せめてスキーマ内では
同じカラムは同じものを表せるように調整しろ

**仕様書無しさん** · 2025/11/16(日) 12:10:28.23

同じカラム名

**仕様書無しさん** · 2025/11/16(日) 12:12:54.68

ねえ

**仕様書無しさん** · 2025/11/16(日) 12:16:32.59

じゃあuserテーブルの属性に全部user_のプレフィックスつけるのかよ

user_name
user_gender
user_email
user_address
user_rank

**仕様書無しさん** · 2025/11/16(日) 12:17:03.89

なんでそう極端なんだよ

**仕様書無しさん** · 2025/11/16(日) 12:20:43.96

db設計むずすぎ

**仕様書無しさん** · 2025/11/16(日) 12:20:58.75

一貫性がある方がいい

idにだけuser_ついてるとなんか気持ち悪い

**仕様書無しさん** · 2025/11/16(日) 12:23:35.94

idにだけuserというか、idとuser_idが両方あるのが現代では普通だと思う
なので選択肢がない

**仕様書無しさん** · 2025/11/16(日) 12:25:04.46

日本語で整理した時どうしてた？

**仕様書無しさん** · 2025/11/16(日) 12:32:49.84

Userテーブルのidなんだからuser.idだろ
user_idは他テーブルの外部キーだろ

**仕様書無しさん** · 2025/11/16(日) 12:33:10.08

idは主キーとして使うと思うけど、これが例えば設計の過程で他に会員番号みたいなものがあってこれを主キーにできる場合はそれをコードでも想像しやすいuser_numberとか使うけど、これがドメインで使われる言葉じゃなくてシステムの都合で必要に迫られて生成した項目の場合はそのままidで使うかな

**仕様書無しさん** · 2025/11/16(日) 12:46:51.30

>>192
だな。ORM使ってるとすべてのテーブルにidがあることが前提だからな

もちろん別のカラム名をidの代わりに利用することも可能だけど面倒なだけなので普通はやらない

ORM使わなくて自分でSQLがりがり書くなら好きなカラム名で良いが、いまどきみんなidがあること前提で読もうとするから不思議に思われるかもな

いつからだろうな。俺はRailsからだけど

**仕様書無しさん** · 2025/11/16(日) 12:48:43.99

>>196
使用するフレームワークのORMに従ったらそうなるだけだろ

**仕様書無しさん** · 2025/11/16(日) 12:49:24.64

じゃあ例えば受注と明細みたいなヘッダーディテール形式
明細レコードには受注IDが入る

受注テーブルの名前をOrderだとすると明細テーブルに入る受注IDは

order_id
parent_id

どっち使う？

**仕様書無しさん** · 2025/11/16(日) 12:51:25.32

受注IDなんだからorder_idにきまってる

**仕様書無しさん** · 2025/11/16(日) 13:17:14.07

基本はドメインで使われる言葉（又はその英訳）をそのまま使うだな
ユビキタス言語

**仕様書無しさん** · 2025/11/16(日) 13:34:20.84

DoctrineかRubyOnRailsかは忘れたが、id列はデータの種類やAppドメインとは無関係な内部値にするべきという考え方が広まってな
orderテーブルだとしてもid列はただのrow idであってorder idではないのさ

**仕様書無しさん** · 2025/11/16(日) 13:40:57.31

知らない土地で目を覚ましたらスマホも財布も貸与PCも全部盗まれてるって夢を見た

**仕様書無しさん** · 2025/11/16(日) 14:27:04.46

ドメイン分析で主キーになりうる一意な項目があるならそれを主キーにするけどな
時々は複合キーも使う（ヘッダー番号+見出し番号とか）
RestAPIのURLだと、〜/bills/101/details/20 みたいな
ORマッパーも複合キーに対応するし
やむを得ない場合はid使うけどそれ以外は
わざわざidの項目増やして管理コスト増やしたくない

**仕様書無しさん** · 2025/11/16(日) 14:29:12.22

誰とでも握手するみたいに、誰とでもセックスする時代になればいいのに

**仕様書無しさん** · 2025/11/16(日) 14:33:00.50

体調崩すからヤダ

**仕様書無しさん** · 2025/11/16(日) 15:08:12.78

そこはうまいことするんだよ

**仕様書無しさん** · 2025/11/16(日) 15:11:10.91

ババアともセックスしなくちゃいけなくなるんだぞ

**仕様書無しさん** · 2025/11/16(日) 15:12:24.60

VRなどで誰とでもセックスできるが実際は誰ともセックスしない世界になるのでほ

**仕様書無しさん** · 2025/11/16(日) 15:20:17.31

>>203
俺も以前はナチュラルキーでやってたけど、もう >>201 みたいな考え方が主流な気がする。複合キーもORMで対応可能とは思うけど、やはりサロゲートキーとユニーク制約にしてしまうな。

**仕様書無しさん** · 2025/11/16(日) 15:21:42.03

生成キーにしたら切り回し難しくないか

**仕様書無しさん** · 2025/11/16(日) 16:18:33.49

会員番号を変更できますとか可変な場合は別途Idを主キーにしといた方が無難
将来にわたって不変の確証あるなら会員番号とかでも構わんと思うけど
ユニーク制約が複数あると大量登録時のパフォーマンスにも多少影響あるしな

**仕様書無しさん** · 2025/11/16(日) 16:21:09.64

会員番号は変更せんやろ…

**仕様書無しさん** · 2025/11/16(日) 16:23:33.87

少々速度が遅くてもいいので変更内容を履歴としてぜんぶ残して時系列遡れるDBにしてほしいんだが
なんでどこも作ろうとせんのだ

**仕様書無しさん** · 2025/11/16(日) 16:25:32.80

使ってないだけか？

**仕様書無しさん** · 2025/11/16(日) 16:28:55.09

>>213
そういう要件で出せば？
やり方は腐る程ある

**仕様書無しさん** · 2025/11/16(日) 16:30:01.33

完全履歴残るファイルベースdbでいい奴があった気がするけど名前が思い出せん

**仕様書無しさん** · 2025/11/16(日) 16:30:38.83

>>213
テーブル設計じゃなくてDBMSレベルの話？

**仕様書無しさん** · 2025/11/16(日) 16:31:00.23

金融だと更新も削除もログとしてひたすら蓄積して、辿ることで現在の状態がわかるようになってるの普通なんじゃないの？
普通は扱いきれないからやらないけど

**仕様書無しさん** · 2025/11/16(日) 16:32:15.78

自分が知ってるどのシステムもアプリで履歴テーブル作ってる

**仕様書無しさん** · 2025/11/16(日) 16:38:34.05

まず >>213 がどのレベルの話をしているのかが判然とせん

**仕様書無しさん** · 2025/11/16(日) 16:41:05.66

どのレベルでもいい
とにかく自分で履歴テーブル作ってアプリで管理するのがめんどい
なんとかならんのか

**仕様書無しさん** · 2025/11/16(日) 16:47:46.38

どのレベルでもいい、じゃなくてどのレベルなのかわからないのでは
たぶん履歴テーブルのこともレスがあるまで知らなかったろ

**仕様書無しさん** · 2025/11/16(日) 16:48:24.28

マウントの機会ばっかり伺ってるんじゃねえ

**仕様書無しさん** · 2025/11/16(日) 16:53:47.50

OracleだとREDOログっていう形で変更履歴は残ってるよね
どのぐらい残るか、それをユーザが使えるのかというのは、DBAじゃないから知らないけど

**仕様書無しさん** · 2025/11/16(日) 16:56:32.10

DB機能の履歴を追う→難しすぎ、データ移行するとデータ消えるので死
アプリの履歴テーブル作る→量がふくらみすぎて処理が複雑化して死
版カラムつけて管理する→SQLが煩雑化したり論理削除フラグのからみが混乱して死

**仕様書無しさん** · 2025/11/16(日) 17:04:08.54

>>204
でもお前、誰とも握手してないよな

**仕様書無しさん** · 2025/11/16(日) 17:05:27.59

ほしいのは多分特定レコードの任意時刻のスナップショットなんだ

**仕様書無しさん** · 2025/11/16(日) 17:14:02.09

きゅうにさびしいことをいうな

**仕様書無しさん** · 2025/11/16(日) 17:14:56.59

ああ、昨日のこいつか >>129

**仕様書無しさん** · 2025/11/16(日) 17:15:26.67

そいつです
たすけて

**仕様書無しさん** · 2025/11/16(日) 17:54:30.51

トリガーで変更前のデータを履歴テーブルに移すのが鉄板
データクソ増えるのはどうしょうもない