なぜusersにカラムを増やさないのか？ それはusersは親tableであり、親tableの更新は常にデッドロックのリスクがあるから。
テーブルを太らせたがる人々と終わり無き抗争を続けているので、こういう明快な根拠はとてもありがたい。
user_token&user_auth_logはよくあるtableである。（中略） SQLやシステム的にも有効なアカウントを見るときはuser_activeだけを見れば良い。 必要な情報は多くはuser_activeとuser_detailをJOINすることで実現するだろう。 JOINのコストはお互いに主キーなので多くのケースは1対1だ。 ここが今回の本質である。
ふむふむ。
以前自分も商品の状態管理が必要なシステムで同じように設計した。同僚からは複雑すぎると不評だったけど、ひとつのテーブルをチクチク更新しなければならないDB設計よりは数段マシだったと思う。