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

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

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

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

増えるほど楽しくなる病にかかることがあります

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

かみのけもふやしてください！

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

AIに聞いたら版カラムつけてnewestフラグ管理がベストプラクティスだって
自分の中で候補のかなり下の方だった…

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

エージェントの担当者から通訳士になるわけでもないのに英語の勉強するのはおかしいと注意されたことあるわ
履歴書から強制的に削除された

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

そんなこと言われてたこともないわ
信用されてなくないか

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

なに書いたんだ

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

フラグ管理は汚いしコード側でフラグ回りの扱いミスるバグを作りまくるゴミだが
一番採用例は多いだろうからAIに聞いたらそうなるだろうな

**仕様書無しさん** · 2025/11/16(日) 19:52:30.65

きれいにソートしてくれて接続先も対応してくれるシステムがあればいいのにな

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

そっとソートしよう

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

A社用フラグ、B社用フラグ、C社用フラグ
A社用ブランチ、B社用ブランチ、C社用ブランチ

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

気合いで並び替えするソート
勝手に変えるなと差し返されるソート

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

>>238
あなたならどうする

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

>>212
会員番号変えてくれってわがままな客がいるんだよ

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

そのキチガイ一人のためにいくら掛けるんだ

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

入会料と退会料の無限ループガチャになりますがよろしいでしょうか？
でよくね

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

肉食うと多少気分が凶暴になってなにかする気になるが凶暴なのでイライラする
食わないと明日にも死ぬジジイみたいな気持ちだ
どうしたものか

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

量を調整しよう

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

そう言えば銅と亜鉛のバランスがイライラや不安感にめっちゃ関係してるらしいよ
量じゃなくてバランス

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

バランスのいい山本選手を見習おう

**仕様書無しさん** · 2025/11/17(月) 00:32:53.30

元気な高齢者は肉食らしい
菜食は不健康

**仕様書無しさん** · 2025/11/17(月) 00:34:00.13

ビタミンとかも摂らなきゃダメなんだろうな

**仕様書無しさん** · 2025/11/17(月) 00:56:54.78

１日分の栄養素が１カプセルに入ってるって怖くね？
３時間分の栄養素くらいの方がちょうどいいだろ

**仕様書無しさん** · 2025/11/17(月) 02:27:34.84

内臓に負担でかそうだよな

**仕様書無しさん** · 2025/11/17(月) 04:09:55.01

履歴管理はマジでめんどくさい
ログだけ簡単だけど、状態の復元とか要件に含まれると辛いよな
大体もっとも能力の高いエンジニアが一人で作らされて、
要件が変わるごとに実装もがらっと変わるから尻拭い的な作業が増える

**仕様書無しさん** · 2025/11/17(月) 10:05:13.23

【犯罪】時間違反SEを退治しろ【損害】

☆時間外労働違反者を退治しろ！☆
★偽装委託多重派遣を退治しろ！★

時間外労働違反のせいで不健康だらけ
多重派遣偽装委託のせいで非婚だらけ

低技術で低収入は高技術で高収入の
技術者に迷惑だからIT業界から失せろ！

**仕様書無しさん** · 2025/11/17(月) 10:05:32.64

【悲報】MicrosoftのWindows開発チーム、Macを使っていることがバレて炎上 [603416639]
https://greta.5ch.net/test/read.cgi/poverty/1763302182/

**仕様書無しさん** · 2025/11/17(月) 10:32:33.11

大量のマジックナンバーに遭遇
しかも調整した的なコメント
どうすりゃいい

**仕様書無しさん** · 2025/11/17(月) 10:36:22.27

全部消せ

**仕様書無しさん** · 2025/11/17(月) 10:39:10.56

こころがくるしい

**仕様書無しさん** · 2025/11/17(月) 10:44:14.77

今日もエージェントから連絡なし

**仕様書無しさん** · 2025/11/17(月) 10:46:33.12

欲しいのは若くて安い有能

**仕様書無しさん** · 2025/11/17(月) 11:13:13.92

同僚が普段から外部とのコネ作りに勤しんでるんだが、真似したほうがいいんだろうか...
来年の契約も怪しいし、今からでも動いていたほうがいいんだろうか...

**仕様書無しさん** · 2025/11/17(月) 11:56:04.78

いい天気や
働きたくない