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

Builderscon 2017で登壇してきました。 builderscon.io 登壇資料はこちらです。 今回も僕が超絶リスペクトしてる id:t-wada さんと そこそこリスペクトしてる 空前絶後のォォ！！！！超絶怒涛にリスペクトしている上司の id:onishi さんの名言を引用させてもらいました。これはテストコードやモニタリングで品質が見える化されますが「見える化されるだけでは問題は解決しない」という本質をお伝えしています。我々はエンジニアなので技術で問題を解決していくわけですし、問題を解決するためには手を動かすしかありません。ですのでまさに今の現場を改善していくのはあなた自身です。 あとは今年、話をしてきたデータベースリファクタリングの総集編って感じです。ホントは実例のRDBアンチパターンを元にリファクタリングしていきたかったんだけど60分では短すぎて「続編に期待」みたいなレベ