実務でゼロからDB設計をしたことがないので、「DB設計筋」をつけるためのトレーニングをしている。具体的に言うと、映画館の発券システムやラーメン屋の注文システムなど、世の中の業務をネタにDB設計を行い、Railsで実装して正しく設計できているかを検証する、ということをしている。
昨年つくった「ポケモンしりとり」や「ゲームソフト管理サービス」はテーブルの数が少なく関連付けもほぼ無いシステムなのでDB設計の経験値を積むことができなかった。それゆえ、関連付けされたモデルをRailsで扱うことにも慣れておらず、DB設計のついでにRailsのベーススキルアップも兼ねている。
開発の流れは、仕様決め→DB設計→実装というシンプルな流れ。サービス開発ではなく学習が目的なため、スピード重視で細部は気にしないように。多少のバグには目を瞑る。あくまでDB設計とバックエンド実装に重きを置いているため、フロントは一切こだわらないことにする。
今回つくったのは「チームメンバー管理システム」。システムは公開していませんが、ソースコードはGitHubあります。
仕様
メンバー管理
- プロジェクトオーナーは「メンバー」を追加できる
- プロジェクトオーナーは「チーム」を作成できる
- チーム作成時に必ずそのチームの「リーダー」を1人指定する
- プロジェクトオーナーはリーダーを後から変更できる
- リーダーは兼任できる
- リーダーは自分のチームにメンバーを参加または外すことができる
- メンバーは複数のチームに所属できる
会議室予約
- プロジェクトオーナーは「会議室」を追加できる
- メンバーは会議室の日時を予約し、会議を開催できる
- 会議の幹事は予約者ではなく、チームリーダーとなる(後から変更もできる)
- 予約済みの日時で別の会議を開催することはできない
- メンバーは自分を含め、他メンバーを会議に参加させることができる
- 会議室には定員があり、定員を超えて参加することはできない
- 幹事だけ会議室の予約破棄ができる
技術書レンタル
- プロジェクトオーナーは「技術書」を追加および削除できる
- メンバーは技術書をレンタルできる(貸出期間は1週間固定)
- レンタルできる技術書は1冊まで
- 貸出期間を過ぎると強制返却される
ER図
画面
今回の気付きなど
DB設計は余計な属性を持たせてしまった点もあったが、大筋問題なく設計できていた。このトレーニングをさらに何度か繰り返すことでより速度と精度を上げられるだろう、ということを実感。続けていく。
ActiveModelのモデル操作に慣れてきた。と同時に、いかに理解不足だったかを再認識した。親モデルをsaveすることで子モデルを登録・更新したり、子モデルを含むFormをつくったり、関連付けされたモデルの操作で躓くことが多かった。慣れたとはいえ、ゴリ押しで実装した感もあるのでリファクタリングの余地は多分にありそう。ただ今回はこれで良しとする。
ルーティングのネストを初めて活用した。よりキレイなURI設計をするにはまだ経験が必要。
rails g scaffold
は便利だが、一気に様々なコード生成してしまうので整理が面倒だと感じた。rails g controller
、rails g model
を使っていくのが良さそう。