[過去ﾛｸﾞ] プログラマの雑談部屋 ★376 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
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(1): 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 がどのレベルの話をしているのかが判然とせん
上下前次1-新書関写板覧索設栞歴
あと 782 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.033s