記事へのコメント88

    • 注目コメント
    • 新着コメント
    オーナーコメントを固定しています
    Soudai
    オーナー Soudai はてぶ数がじょーかーさんになってた

    2018/05/03 リンク

    その他
    enemyoffreedom
    enemyoffreedom 2018年の記事

    2023/08/17 リンク

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

    2022/06/29 リンク

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

    2020/04/13 リンク

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

    2020/03/05 リンク

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

    2019/05/01 リンク

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

    2018/10/11 リンク

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

    2018/05/15 リンク

    その他
    tankdesant
    tankdesant q

    2018/05/10 リンク

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

    2018/05/08 リンク

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

    2018/05/07 リンク

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

    2018/05/06 リンク

    その他
    hiroponz
    hiroponz すごいためになる

    2018/05/06 リンク

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

    2018/05/05 リンク

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

    2018/05/05 リンク

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

    2018/05/04 リンク

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

    2018/05/04 リンク

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

    2018/05/04 リンク

    その他
    sue445
    sue445 1000はてブじゃん

    2018/05/03 リンク

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

    2018/05/03 リンク

    その他
    toritori0318
    toritori0318 議論が面白い

    2018/05/03 リンク

    その他
    side_tana
    side_tana 参考になる

    2018/05/03 リンク

    その他
    ainame
    ainame 設計知見の共有良い

    2018/05/03 リンク

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

    2018/05/03 リンク

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

    2018/05/03 リンク

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

    2018/05/02 リンク

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

    2018/05/02 リンク

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

    2018/05/02 リンク

    その他
    yugui
    yugui これは良いまとめ

    2018/05/02 リンク

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

    2018/05/02 リンク

    その他
    versatile
    versatile log は db にいれなくて kvs にするとかにしたいライフ

    2018/05/02 リンク

    その他

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

    アプリのスクリーンショット
    いまの話題をアプリでチェック!
    • バナー広告なし
    • ミュート機能あり
    • ダークモード搭載
    アプリをダウンロード

    関連記事

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


       ...    

    ブックマークしたユーザー

    • mihyaeru212024/05/25 mihyaeru21
    • bamch0h2024/02/27 bamch0h
    • supaiku24522024/02/15 supaiku2452
    • dom2h2024/02/14 dom2h
    • tosi292024/02/14 tosi29
    • ihirokyx2024/02/14 ihirokyx
    • buzztaiki2024/02/14 buzztaiki
    • nishitki2024/02/13 nishitki
    • t0m02024/02/13 t0m0
    • kirikiriyamama2023/10/19 kirikiriyamama
    • JUN_NETWORKS2023/09/25 JUN_NETWORKS
    • abekoh2023/09/13 abekoh
    • sh0g02023/09/13 sh0g0
    • enemyoffreedom2023/08/17 enemyoffreedom
    • fjwr382023/04/05 fjwr38
    • tomiyanx2023/01/13 tomiyanx
    • shifumin2022/11/23 shifumin
    • subprotein2022/10/13 subprotein
    すべてのユーザーの
    詳細を表示します

    同じサイトの新着

    同じサイトの新着をもっと読む

    いま人気の記事

    いま人気の記事をもっと読む

    いま人気の記事 - テクノロジー

    いま人気の記事 - テクノロジーをもっと読む

    新着記事 - テクノロジー

    新着記事 - テクノロジーをもっと読む

    同時期にブックマークされた記事