会社のさまざまな部門のさまざまな人がログインしてフォームを編集できるようにするアプリケーションに取り組んでいます。各部門には、編集および表示が許可されているフォーム内の特定のフィールドがあります。
フィールドのセット全体に対して 1 つのモデルを作成し、ログインしたユーザーに基づいて、必要なフィールドを含む別のフォームをレンダリングすると、コードがより整理されますか? それとも、部門固有のフィールドを独自のモデルに分割し、ログインしたユーザーに基づいて、特定のフィールドを含むフォームをレンダリングし、さまざまな部門のレコードを何らかの外部キーを介して関連付ける方がよいでしょうか?
「場合による」がおそらく最良の答えです。フィールドはいくつありますか？部門フォームの種類ごとにいくつのロジックが存在しますか?
すべてのフィールドを別々のモデル (および対応するテーブル) に分割すると、入力後にフォームの完全な概要が必要になると、フォームが別々のテーブルになるため、面倒になります。完全なフォームを取得するには、フォームのすべての関連付けを実行する必要があります。
部門ごとに多くのロジックがあるため、それらを分割したい場合は、table_nameを使用して、すべてのフィールドを含む 1 つの「メイン」テーブルにすべてのモデルをポイントできます。そうすれば、すべてのデータが 1 つのテーブルに格納され、簡単に取得できます。ただし、フォームのタイプを正しいモデルで取得するには、フォームのタイプも保存する必要があります。(すべてのフィールドを 1 つのテーブルに保存するのが最善である場合は、取得される頻度や挿入/更新される頻度も異なります。)
単純なフォームは、おそらく 1 つのモデルにうまく適合します。部門ごとに共有できないコードが大量にない限り、フォームを別々のモデルに分割する価値はおそらくありません。フォームをモデルに分割する場合は、メイン フォーム モデルを 1 つ作成し、再利用可能なフォーム ロジックがあればそれを部門モデルに拡張させる必要があります。
結局のところ、私はシンプルさを好むので、おそらく 1 つのモデルに保存したいと思います。
フィールドを分割すると、accepts_nested_attributes_forを使用してモデルをセットアップし、フォームを適切に構築できます。