前回から更に半年経ったので振り返る。 soudai.hatenablog.com 前提 今は株式会社 オミカレって会社でCTOをしてる。 オミカレは婚活パーティーのポータルサイトで、男女問わず、幅広い年齢をカバーした婚活パーティーを取り扱っている。 party-calendar.net もうサイトとしては8年目で息の長いサービスとなっており、レガシィなところも目立ってきた。 それを払拭するためにチーム、サービス、ビジネスの3本柱をメンテナンスしてるフェーズ。 この半年は前回のまとめに書いた通り、大きな目標が2つあった。 自立型のチームとして確立する 売上をしっかり伸ばす それを踏まえて、振り返りをしていく。 10月 スマホアプリがリリースされた。 春からずっとここに標準を合わせて、アプリケーションの設計やらプロジェクト管理やらAPI作成やらしてたので無事出たことに驚きと共に、そんなに大きな

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