プログラマの雑談部屋 ★376 (233ﾚｽ)
上下前次1-新
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
146: 11/15(土)23:40 AAS
お前らみたいに有能なプログラマーになりたいのでご教授くださいやがれ
147(1): 11/15(土)23:40 AAS
ORMあっても簡単なER図書かない？
148: 11/15(土)23:46 AAS
うんこが便器から飛び出しているかテストするときに
・うんこが完全に便器の中にある
・うんこが半分飛び出している
・うんこが完全に飛び出している
・うんこが便器をまたいで飛び出している
の境界テストをすればいいだけなのだが
センスのない奴にテスト仕様を書かせると
省5
149(1): 11/15(土)23:50 AAS
>>147
書かない
つうか最近のDBツールだとER図みたいな画面持ってるやん
なんで書くのよ
150: 11/16(日)00:00 AAS
>>149
設計段階でまずどんなん作るか決めなあかんやん
そこもDBツールで書いちゃうの？
151: 11/16(日)00:01 AAS
テーブルは適度に非正規化しないとパフォーマンス落ちるやろ
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のみでも運用できる
省12
154(1): 11/16(日)00:06 AAS
🔥 生SQLだけで運用すると破綻する理由
1. スキーマ変更の影響範囲が手作業で対応しきれない
例：カラム名1つ変えるだけで数百ファイルに影響する可能性。
ORMならモデル1箇所を直せばよいが、生SQLでは全部探す必要がある。
2. SQLがどこで使われているかコード上から追えない
生SQLは散らばりやすい
grep 検索では限界がある
省9
155: 11/16(日)00:07 AAS
🔧 実務では何が起きるか？
100テーブル → 「なんとかなる」
SQLが複雑になっても人間が把握できる
200テーブル → 「構造管理が苦しくなる」
影響範囲調査が辛い
スキーマ変更のたびに改修数が膨れ上がる
300テーブル以上 → 「保守不能に近い」
省9
156: 11/16(日)00:07 AAS
✅ 最終結論
「生SQLだけ」でやりやすいテーブル数の目安は 〜100
150〜200でギリギリ、300以上は非推奨
ただし以下によって変わります：
チーム全員がSQLに強いか？
スキーマ変更が頻繁か？
分析系か、トランザクション系か？
省1
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はサロゲートキーにしか使ってねえや
182: 11/16(日)12:06 AAS
社員番号のような何かはuser_idに入れる。
idはレコードそのものユニークIDを入れる列名として定着してるから、そこに社員番号を入れるのはもはや嫌がらせに近い。
183: 11/16(日)12:08 AAS
userテーブルの主キーはidだろ
テーブル名がuserだからuser_idは冗長だわ
外部キーとして使う時はuser_idだけど
184: 11/16(日)12:09 AAS
そんなことより、ユーザ管理すりテーブル
が何なのか気になるわ
185: 11/16(日)12:10 AAS
やめておけ
せめてスキーマ内では
同じカラムは同じものを表せるように調整しろ
186: 11/16(日)12:10 AAS
同じカラム名
187: 11/16(日)12:12 AAS
ねえ
188: 11/16(日)12:16 AAS
じゃあuserテーブルの属性に全部user_のプレフィックスつけるのかよ
user_name
user_gender
user_email
user_address
user_rank
189: 11/16(日)12:17 AAS
なんでそう極端なんだよ
190: 11/16(日)12:20 AAS
db設計むずすぎ
191: 11/16(日)12:20 AAS
一貫性がある方がいい
idにだけuser_ついてるとなんか気持ち悪い
192(1): 11/16(日)12:23 AAS
idにだけuserというか、idとuser_idが両方あるのが現代では普通だと思う
なので選択肢がない
193: 11/16(日)12:25 AAS
日本語で整理した時どうしてた？
194: 11/16(日)12:32 AAS
Userテーブルのidなんだからuser.idだろ
user_idは他テーブルの外部キーだろ
195: 11/16(日)12:33 AAS
idは主キーとして使うと思うけど、これが例えば設計の過程で他に会員番号みたいなものがあってこれを主キーにできる場合はそれをコードでも想像しやすいuser_numberとか使うけど、これがドメインで使われる言葉じゃなくてシステムの都合で必要に迫られて生成した項目の場合はそのままidで使うかな
196(1): 11/16(日)12:46 AAS
>>192
だな。ORM使ってるとすべてのテーブルにidがあることが前提だからな
もちろん別のカラム名をidの代わりに利用することも可能だけど面倒なだけなので普通はやらない
ORM使わなくて自分でSQLがりがり書くなら好きなカラム名で良いが、いまどきみんなidがあること前提で読もうとするから不思議に思われるかもな
いつからだろうな。俺はRailsからだけど
197: 11/16(日)12:48 AAS
>>196
使用するフレームワークのORMに従ったらそうなるだけだろ
198: 11/16(日)12:49 AAS
じゃあ例えば受注と明細みたいなヘッダーディテール形式
明細レコードには受注IDが入る
受注テーブルの名前をOrderだとすると明細テーブルに入る受注IDは
order_id
parent_id
どっち使う？
199: 11/16(日)12:51 AAS
受注IDなんだからorder_idにきまってる
200: 11/16(日)13:17 AAS
基本はドメインで使われる言葉（又はその英訳）をそのまま使うだな
ユビキタス言語
201(1): 11/16(日)13:34 AAS
DoctrineかRubyOnRailsかは忘れたが、id列はデータの種類やAppドメインとは無関係な内部値にするべきという考え方が広まってな
orderテーブルだとしてもid列はただのrow idであってorder idではないのさ
202: 11/16(日)13:40 AAS
知らない土地で目を覚ましたらスマホも財布も貸与PCも全部盗まれてるって夢を見た
203(1): 11/16(日)14:27 AAS
ドメイン分析で主キーになりうる一意な項目があるならそれを主キーにするけどな
時々は複合キーも使う（ヘッダー番号+見出し番号とか）
RestAPIのURLだと、〜/bills/101/details/20 みたいな
ORマッパーも複合キーに対応するし
やむを得ない場合はid使うけどそれ以外は
わざわざidの項目増やして管理コスト増やしたくない
204(1): 11/16(日)14:29 AAS
誰とでも握手するみたいに、誰とでもセックスする時代になればいいのに
205: 11/16(日)14:33 AAS
体調崩すからヤダ
206: 11/16(日)15:08 AAS
そこはうまいことするんだよ
207: 11/16(日)15:11 AAS
ババアともセックスしなくちゃいけなくなるんだぞ
208: 11/16(日)15:12 AAS
VRなどで誰とでもセックスできるが実際は誰ともセックスしない世界になるのでほ
209: 11/16(日)15:20 AAS
>>203
俺も以前はナチュラルキーでやってたけど、もう >>201 みたいな考え方が主流な気がする。複合キーもORMで対応可能とは思うけど、やはりサロゲートキーとユニーク制約にしてしまうな。
210: 11/16(日)15:21 AAS
生成キーにしたら切り回し難しくないか
211: 11/16(日)16:18 AAS
会員番号を変更できますとか可変な場合は別途Idを主キーにしといた方が無難
将来にわたって不変の確証あるなら会員番号とかでも構わんと思うけど
ユニーク制約が複数あると大量登録時のパフォーマンスにも多少影響あるしな
212: 11/16(日)16:21 AAS
会員番号は変更せんやろ…
213(3): 11/16(日)16:23 AAS
少々速度が遅くてもいいので変更内容を履歴としてぜんぶ残して時系列遡れるDBにしてほしいんだが
なんでどこも作ろうとせんのだ
214: 11/16(日)16:25 AAS
使ってないだけか？
215: 11/16(日)16:28 AAS
>>213
そういう要件で出せば？
やり方は腐る程ある
216: 11/16(日)16:30 AAS
完全履歴残るファイルベースdbでいい奴があった気がするけど名前が思い出せん
217: 11/16(日)16:30 AAS
>>213
テーブル設計じゃなくてDBMSレベルの話？
218: 11/16(日)16:31 AAS
金融だと更新も削除もログとしてひたすら蓄積して、辿ることで現在の状態がわかるようになってるの普通なんじゃないの？
普通は扱いきれないからやらないけど
219: 11/16(日)16:32 AAS
自分が知ってるどのシステムもアプリで履歴テーブル作ってる
220: 11/16(日)16:38 AAS
まず >>213 がどのレベルの話をしているのかが判然とせん
221: 11/16(日)16:41 AAS
どのレベルでもいい
とにかく自分で履歴テーブル作ってアプリで管理するのがめんどい
なんとかならんのか
222: 11/16(日)16:47 AAS
どのレベルでもいい、じゃなくてどのレベルなのかわからないのでは
たぶん履歴テーブルのこともレスがあるまで知らなかったろ
223: 11/16(日)16:48 AAS
マウントの機会ばっかり伺ってるんじゃねえ
224: 11/16(日)16:53 AAS
OracleだとREDOログっていう形で変更履歴は残ってるよね
どのぐらい残るか、それをユーザが使えるのかというのは、DBAじゃないから知らないけど
225: 11/16(日)16:56 AAS
DB機能の履歴を追う→難しすぎ、データ移行するとデータ消えるので死
アプリの履歴テーブル作る→量がふくらみすぎて処理が複雑化して死
版カラムつけて管理する→SQLが煩雑化したり論理削除フラグのからみが混乱して死
226: 11/16(日)17:04 AAS
>>204
でもお前、誰とも握手してないよな
上下前次1-新書関写板覧索設栞歴
あと 7 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.013s