プログラマの雑談部屋 ★376 (193ﾚｽ)
上下前次1-新
126(1): 11/15(土)22:26 AAS
きれいなコードになるデータ構成がどんなのかデータだけ見てわかるのか？
127: 11/15(土)22:29 AAS
最初は綺麗なんだよなぁ
頑張って設計したし
でも追加機能やら改修やらで綺麗にするとソースコードの修正範囲が大きくなるからツギハギして行くうちにゴミ化して来る
128(1): 11/15(土)22:36 AAS
事業会社なんかはサービスの売り上げ、
（当然だけど）ビジネスありきであるわけだから、求められるのは巧遅よりも拙速であり、データは自然と継ぎ足しに
コードはそうしたデータの尻拭い
結果としてのスパゲティ
>>126
少なくとも上記のような環境でなけりゃデータの設計しっかりするでしょ
129(1): 11/15(土)22:39 AAS
・時間によってバージョン切り替えするようなマスタをどうやって設計しますか？
開始時間と終了時間の両方をカラム含めさせますか？
ビューを付けたほうがいいでしょうか？
・リカーシブな読み込み前提のテーブルを作ってもいいでしょうか？後々面倒はないでしょうか？
・レコードの版をどうやって管理しますか？結合するときに面倒はないでしょうか？
・論理削除使いますか？部分的に削除したのと、親ごと削除したのと区別が付きますか。削除した情報を見たいなんて要求があるとき、どうしますか？
130: 11/15(土)22:42 AAS
協力会社の技術力のあるエンジニアを信用して任せてたらその会社の他のプロジェクトが忙しくなってそちらに手を取られて、うちの仕事はそこの外注の初心者みたいなエンジニアに投げられてぐちゃぐちゃなコードを量産しまくられて挙句の果てに協力会社ごと逃げられたことがある。今でもその時のゴミコードでバグが発生してメンテする手間がかかっている。まぁその当時のうちの人間がすべてをレビューしてなかったのも問題だとは思うが（私はいなかったので知らん）
131(1): 11/15(土)22:43 AAS
今はAIが全てのベストプラクティスをご存知なのでまだいい
当時はひとつひとつが鬼門だった
いや今でもサボったほうが楽なことが多くて後々地獄になる
簡単そうには見えるんだが
個々のSQLの膨らみ具合と
こんなはずじゃない勢いのテーブル増加を見て怖気づく
132(1): 11/15(土)22:48 AAS
>>128
まさにその状態の真っ只中にいる。とにかく責任者が思いついたらその機能を2-3日みたいなスパンで投入しないといけないのでじっくり設計とかしている暇はない。いまこれリリースしたらトラブル可能性ありますよと言ってもとにかく機能が欲しい、トラブっても動かしながら直せばいいみたいな感じ
まぁ結論としてはまともなエンジニアリングをしている会社で働こう！ということだなw
133: 11/15(土)22:51 AAS
うそです会社で設計したことない
ジジイなので記憶が改竄されてた
134: 11/15(土)22:52 AAS
>>131
テーブルやSQLが複雑になってももう気にしなくてもよいのでは？自分で書く時代は終わってAIに任せておけば複雑なSQLも一瞬で仕上げてくれるんだし。必死で勉強して大量にSQL書いてきたけど、まったくもってAIの書くスピードとSQLの内容のスマートさにはかなわんわ
135: 11/15(土)22:54 AAS
ああそっか…
時代はかわったんだ…
136: 11/15(土)22:55 AAS
下剤効いて2kg出た
137: 11/15(土)22:57 AAS
なにもさせてもらえなかった
社会に影響を与えるチャンスは
ことごとく足払いをかけられて潰されてきた
138: 11/15(土)22:58 AAS
>>132
まともなエンジニアリングしてる大手有名会社がそういう事してるからだよ
MSとかAppleとかAWSとかGoogleとかMetaとかその他諸々
139: 11/15(土)22:59 AAS
自分の状況は悪くはない
悪くはないが結局は社会に消されたんだ
140(1): 11/15(土)23:00 AAS
>>129
>時間によってバージョン切り替え
バージョンによって、じゃなくてマスタ切り替えではなくて？
>開始時間と終了時間の両方をカラム
判然とせんけどたぶんイエス
>ビューを付けたほうがいいでしょうか？
省10
141: 11/15(土)23:02 AAS
>>140
標準的な人間の回答をありがとう
見通しが立たなくてわからんから聞いてるんだが結局人間じゃこういう回答が返ってくるよな
当然だ
AIなら
142: 11/15(土)23:33 AAS
テーブル数多くなってきたらGUIかORM使うのが普通になってくるってこと？
CLIとか素のSQL文の管理とかできる気がしないんだけど
143: 11/15(土)23:33 AAS
テーブル数多い時にね
144: 11/15(土)23:36 AAS
GUIかORMて
145: 11/15(土)23:38 AAS
納豆パン作ってみたらめちゃくちゃまずかった
大豆はまだ食えたんだが
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: 11/16(日)12:23 AAS
idにだけuserというか、idとuser_idが両方あるのが現代では普通だと思う
なので選択肢がない
193: 11/16(日)12:25 AAS
日本語で整理した時どうしてた？
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.013s