![](https://cdn-ak-scissors.b.st-hatena.com/image/square/400a46405250d511b09478fcc17bf1d114ab46cf/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2FS%2FSoudai%2F20180501%2F20180501192200.png)
エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント88件
- 注目コメント
- 新着コメント
![yamaz yamaz](https://cdn.profile-image.st-hatena.com/users/yamaz/profile.png)
yamaz
ちょうど社内でこの話題が出てるのですが、セキュリティ的な観点でログイン時だけに必要な情報と、個人情報が必要なケースに参照すべきテーブルは別々にして必要な参照権限も別にするべきだと思うのでした。
![salamander_jp salamander_jp](https://cdn.profile-image.st-hatena.com/users/salamander_jp/profile.png)
salamander_jp
テーブル名を単数形か複数形に統一してほしい人生だった。ちなみに、sakila先輩にはactiveカラムがある模様。Laravel先輩はdeleted_atで論理削除する模様。
![otchy210 otchy210](https://cdn.profile-image.st-hatena.com/users/otchy210/profile.png)
otchy210
deleted フラグを避けるために、deleted_users にレコードを移動する設計をしたことがある。それをさらに進めた感じ。とは言え現代では個人情報を持つリスクが大きく、 不要になったら極力削除したいわけで悩みは深い。
![rizmhate rizmhate](https://cdn.profile-image.st-hatena.com/users/rizmhate/profile.png)
rizmhate
状態毎にテーブルかー、今までだと、ステータスカラム追加で事足りてたな。。。
![Chisei Chisei](https://cdn.profile-image.st-hatena.com/users/Chisei/profile.png)
Chisei
物理削除したいのだが他サービスに削除を伝達したいときは deleted_uses table が欲しくなる。temporary な状態かつ発番したくない場合は別ストレージに格納が良いと考えている。
![jsstudy jsstudy](https://cdn.profile-image.st-hatena.com/users/jsstudy/profile.png)
jsstudy
2018-05-01 ・テーブルに状態を持たせず状態毎のテーブルを作る・状態が変わればレコードを消して別のtableに作る・tableの普遍的な情報は別に持たせる [users]親table、基本はINSERTのみでUPDATE、DELETEを考慮しない。
![joker1007 joker1007](https://cdn.profile-image.st-hatena.com/users/joker1007/profile.png)
joker1007
confirm待ちとactiveなユーザー自体を分けるのは基本だと思う。propertyの持ち方はサービス特性に依存するので何とも言えないがEAVとJSONは選択肢に入る。削除は本当に辛い。DWH系のストアに入れたデータは特に。
![xorphitus xorphitus](https://cdn.profile-image.st-hatena.com/users/xorphitus/profile.png)
xorphitus
自分のDB設計力上げなきゃなと思いながらリプ含め眺めたが、これならlog tableの外部キーを外す方向に考えたくなるなあ。よくあるtableとのことだけど、これって何が求められてるんだっけ
![tmatsuu tmatsuu](https://cdn.profile-image.st-hatena.com/users/tmatsuu/profile.png)
tmatsuu
現場から離れて久しいがマスター系の制約はCASCADEもしくはRESTRICT、トランザクション系の制約はON UPDATE CASCADE ON DELETE SET NULLってやってた気がする。
![yositosi yositosi](https://cdn.profile-image.st-hatena.com/users/yositosi/profile.png)
yositosi
一部で使ってみてるけど、基本的に参照も更新も手数が増える印象。セキュアな情報とかほとんど必要ないステータスみたいな時以外はあまり有効ではないのでは?ORMとか使ってるとそれこそJOINが爆発しそう。
![ghostbass ghostbass](https://cdn.profile-image.st-hatena.com/users/ghostbass/profile.png)
ghostbass
ユーザーの状態が増えたらテーブルが増えるって構造が個人的には受け入れられない。とあるユーザーの今の状態は?みたいな問い合わせが辛く感じる。けどそういうユースケースがないと仮定できるなら…
![ardarim ardarim](https://cdn.profile-image.st-hatena.com/users/ardarim/profile.png)
ardarim
user_activeとuser_leaveが排他用途でDB最適化の観点からはイマイチだし、そもそもここで結局トランザクションを意識しなければならないのでは。退会ユーザを残すこと自体はなりすましとかを考慮すると必要かな
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
いまの話題をアプリでチェック!
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の...
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作るtableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
2018/05/03 リンク