【移行記事】Railsでチームメンバー管理システムをつくった(DB設計学習第一弾)

23:17:48

実務でゼロから DB 設計をしたことがないので、「DB 設計筋」をつけるためのトレーニングをしている。具体的に言うと、映画館の発券システムやラーメン屋の注文システムなど、世の中の業務をネタに DB 設計を行い、Rails で実装して正しく設計できているかを検証する、ということをしている。

昨年つくった「ポケモンしりとり」や「ゲームソフト管理サービス」はテーブルの数が少なく関連付けもほぼ無いシステムなので DB 設計の経験値を積むことができなかった。それゆえ、関連付けされたモデルを Rails で扱うことにも慣れておらず、DB 設計のついでに Rails のベーススキルアップも兼ねている。

開発の流れは、仕様決め →DB 設計 → 実装というシンプルな流れ。サービス開発ではなく学習が目的なため、スピード重視で細部は気にしないように。多少のバグには目を瞑る。あくまで DB 設計とバックエンド実装に重きを置いているため、フロントは一切こだわらないことにする。

今回つくったのは「チームメンバー管理システム」。システムは公開していませんが、ソースコードは GitHub あります。

仕様

メンバー管理

・プロジェクトオーナーは「メンバー」を追加できる・プロジェクトオーナーは「チーム」を作成できる・チーム作成時に必ずそのチームの「リーダー」を 1 人指定する・プロジェクトオーナーはリーダーを後から変更できる・リーダーは兼任できる・リーダーは自分のチームにメンバーを参加または外すことができる・メンバーは複数のチームに所属できる

会議室予約

・プロジェクトオーナーは「会議室」を追加できる・メンバーは会議室の日時を予約し、会議を開催できる・会議の幹事は予約者ではなく、チームリーダーとなる(後から変更もできる)・予約済みの日時で別の会議を開催することはできない・メンバーは自分を含め、他メンバーを会議に参加させることができる・会議室には定員があり、定員を超えて参加することはできない・幹事だけ会議室の予約破棄ができる

技術書レンタル

・プロジェクトオーナーは「技術書」を追加および削除できる・メンバーは技術書をレンタルできる(貸出期間は 1 週間固定)・レンタルできる技術書は 1 冊まで・貸出期間を過ぎると強制返却される

ER 図

以下、今回の気付きなど。

・DB 設計は余計な属性を持たせてしまった点もあったが、大筋問題なく設計できていた。このトレーニングをさらに何度か繰り返すことでより速度と精度を上げられるだろう、ということを実感。続けていく。

・ActiveModel のモデル操作に慣れてきた。と同時に、いかに理解不足だったかを再認識した。親モデルを save することで子モデルを登録・更新したり、子モデルを含む Form をつくったり、関連付けされたモデルの操作で躓くことが多かった。慣れたとはいえ、ゴリ押しで実装した感もあるのでリファクタリングの余地は多分にありそう。ただ今回はこれで良しとする。

・ルーティングのネストを初めて活用した。よりキレイな URI 設計をするにはまだ経験が必要。

・rails g scaffold は便利だが、一気に様々なコード生成してしまうので整理が面倒だと感じた。<code>rails g controller</code>、<code>rails g model</code>を使っていくのが良さそう。