テクノロジー
ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳

気に入った記事をブックマーク

気に入った記事を保存できます
保存した記事の一覧は、はてなブックマークで確認・編集ができます
記事を読んだ感想やメモを書き残せます
非公開でブックマークすることもできます

ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳

テクノロジーカテゴリーの変更を依頼記事元:

soudai.hatenablog.com

適切な情報に変更

エントリーの編集

エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。

このページのオーナーなので以下のアクションを実行できます

タイトル、本文などの情報を
再取得することができます

コメントを非表示にできますコメント表示の設定

ブックマークしました

ここにツイート内容が記載されますhttps://b.hatena.ne.jp/URLはspanで囲んでください

Twitterで共有

次回からTwitterへ自動リダイレクト

ONにすると、次回以降このダイアログを飛ばしてTwitterに遷移します

1152usersがブックマークコメント

コメントするにはログインが必要ですブックマークを追加

ブックマークを追加

よく使うタグ

ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳

1152 users

soudai.hatenablog.com

よく使うタグ

はてなブックマークで
関心をシェアしよう

みんなの興味と感想が集まることで
新しい発見や、深堀りがもっと楽しく

ユーザー登録

アカウントをお持ちの方はログインページへ

記事へのコメント87件

注目コメント
新着コメント

オーナーコメントを固定しています

オーナーSoudaiはてぶ数がじょーかーさんになってた

2018/05/03リンク

その他

yamazちょうど社内でこの話題が出てるのですが、セキュリティ的な観点でログイン時だけに必要な情報と、個人情報が必要なケースに参照すべきテーブルは別々にして必要な参照権限も別にするべきだと思うのでした。

2018/05/01リンク

その他

htnmikiこんな枯れた要件でもベストプラクティス的なものがないというのが非IT系の者としては驚きだ

2018/05/02リンク

その他

wkubotaだいたい同意。というか普段、似たような設計をしていたし、見かける形でもある。こうして公開することに価値のある知見だよなぁ。

2018/05/02リンク

その他

nazokinglog系を外部制約から外した方がいろいろ捗るはず…？

2018/05/02リンク

その他

otchy210deleted フラグを避けるために、deleted_users にレコードを移動する設計をしたことがある。それをさらに進めた感じ。とは言え現代では個人情報を持つリスクが大きく、不要になったら極力削除したいわけで悩みは深い。

2018/05/01リンク

その他

turanukimaruuser_detailは有効期限をつけたうえで更新するときはupdateではなくinsertする形が好き。

2018/05/02リンク

その他

rizmhate状態毎にテーブルかー、今までだと、ステータスカラム追加で事足りてたな。。。

2018/05/02リンク

その他

syossan非常にわかりみしかない

2018/05/02リンク

その他

koyancyauser が active なのかどうかというのは DB は知ったことではない（アプリが決める）ので lock とか leave とか temp だけがあって、みたいにする

2018/05/02リンク

その他

オーナーコメントを固定しています

オーナーSoudaiはてぶ数がじょーかーさんになってた

2018/05/03リンク

その他

enemyoffreedom2018年の記事

2023/08/17リンク

その他

dorapon2000“なぜusersにカラムを増やさないのか？それはusersは親tableであり、親tableの更新は常にデッドロックのリスクがあるから。”

2022/06/29リンク

その他

iga_k そーだい先生のusersテーブル設計。知見。

2020/04/13リンク

その他

Chisei物理削除したいのだが他サービスに削除を伝達したいときは deleted_uses table が欲しくなる。temporary な状態かつ発番したくない場合は別ストレージに格納が良いと考えている。

2020/03/05リンク

その他

jsstudy2018-05-01　・テーブルに状態を持たせず状態毎のテーブルを作る・状態が変わればレコードを消して別のtableに作る・tableの普遍的な情報は別に持たせる　[users]親table、基本はINSERTのみでUPDATE、DELETEを考慮しない。

2019/05/01リンク

その他

takets 今は10%も理解できてないので、保存して必要になったら読み返す。

2018/10/11リンク

その他

usadamasa“しかしここでは適宜トランザクション利用することは人類には難しいという大前提で話をする。”

2018/05/15リンク

その他

tankdesantq

2018/05/10リンク

その他

mu2inテーブル設計ってわりと初期にやる分おろそかになりがちな感じ

2018/05/08リンク

その他

ymm1xなぜ状態テーブルに分けるのかあまりしっくりきてない。まとめるとアプリ側で xlock を扱いたくないでござるというのと状態フラグは作りたくないでござるというところでいいのかしら。

2018/05/07リンク

その他

sylvan_l ユーザ情報を保存する時のテーブル設計

unclassified

2018/05/06リンク

その他

hiroponzすごいためになる

2018/05/06リンク

その他

joker1007confirm待ちとactiveなユーザー自体を分けるのは基本だと思う。propertyの持ち方はサービス特性に依存するので何とも言えないがEAVとJSONは選択肢に入る。削除は本当に辛い。DWH系のストアに入れたデータは特に。

database

2018/05/05リンク

その他

xorphitus自分のDB設計力上げなきゃなと思いながらリプ含め眺めたが、これならlog tableの外部キーを外す方向に考えたくなるなあ。よくあるtableとのことだけど、これって何が求められてるんだっけ

2018/05/05リンク

その他

tmatsuu現場から離れて久しいがマスター系の制約はCASCADEもしくはRESTRICT、トランザクション系の制約はON UPDATE CASCADE ON DELETE SET NULLってやってた気がする。

2018/05/04リンク

その他

trashtoy自分の場合はモデルとして自然かどうかを最優先するかも

2018/05/04リンク

その他

cocoasynn自分も思想的には似たような感じにテーブルを分割したいんだけど、色々複雑になりすぎる印象があるし場合によってはパフォーマンスに問題も出てきそうで悩ましい。

2018/05/04リンク

その他

sue4451000はてブじゃん

2018/05/03リンク

その他

style_blue ユーザーアカウントひとつ取ってもここまで細分化するものなのか。なるほど勉強になる。

開発

2018/05/03リンク

その他

toritori0318議論が面白い

database

2018/05/03リンク

その他

side_tana参考になる

2018/05/03リンク

その他

ainame設計知見の共有良い

2018/05/03リンク

その他

codehexマサカリ含めて参考になる

2018/05/03リンク

その他

progrhymeミニマルな親テーブルを作る。なるほど

2018/05/03リンク

その他

regularexception設計でどうこうするんじゃなくて、ストレージ（DB)側がなんかしてくれればいいのに

2018/05/02リンク

その他

yositosi一部で使ってみてるけど、基本的に参照も更新も手数が増える印象。セキュアな情報とかほとんど必要ないステータスみたいな時以外はあまり有効ではないのでは？ORMとか使ってるとそれこそJOINが爆発しそう。

2018/05/02リンク

その他

ghostbassユーザーの状態が増えたらテーブルが増えるって構造が個人的には受け入れられない。とあるユーザーの今の状態は？みたいな問い合わせが辛く感じる。けどそういうユースケースがないと仮定できるなら…

2018/05/02リンク

その他

yuguiこれは良いまとめ

2018/05/02リンク

その他

ardarimuser_activeとuser_leaveが排他用途でDB最適化の観点からはイマイチだし、そもそもここで結局トランザクションを意識しなければならないのでは。退会ユーザを残すこと自体はなりすましとかを考慮すると必要かな

データベース

2018/05/02リンク

その他

versatilelog は db にいれなくて kvs にするとかにしたいライフ

2018/05/02リンク

その他

コメントするにはログインが必要ですログインしてコメント

注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

リンクを埋め込む

以下のコードをコピーしてサイトに埋め込むことができます

プレビュー

はてなブックマークボタンを作成して埋め込むこともできます

規約違反を報告

いまの話題をアプリでチェック！

バナー広告なし
ミュート機能あり
ダークモード搭載

アプリをダウンロード

usersに達しました！

さんが1番目にブックマークした記事「ユーザ情報を保存...」が注目されています。

気持ちをシェアしよう

ツイートする

ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳

はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません用法用量を守り、個人の...はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません用法用量を守り、個人の責任で業務に投入してください参考資料 2024/02/14追記実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか今北産業で頼むテーブルに状態を持たせず状態毎のテーブルを作る状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録