実現したいこと
(タイトルがわかりにくくてすみません)
Model_A と Document とモデルがあり、1対N のリレーションになってます。
SELECT * FROM DOCUMENTS; id | model_a_id | summary | deleted_at | created_at | updated_at ----+------------+---------+------------+------------+------------ \d documents; Table "public.documents" Column | Type | Collation | Nullable | Default ---------------+--------------------------------+-----------+----------+--------------------------------------- id | bigint | | not null | nextval('documents_id_seq'::regclass) model_a_id | bigint | | not null | summary | character varying | | | deleted_at | timestamp(6) without time zone | | | created_at | timestamp(6) without time zone | | not null | updated_at | timestamp(6) without time zone | | not null |
(例としては、Model_A が一軒家のデータで、それに設計図やら申請書やらなど複数書類をDocument として紐付けることができる、みたいな感じ)
これを元に新たに、Model_B、Model _C の追加を考えてます。各モデルはカラムが違いすぎて、モデルを共通化できないことを前提とします。
(例としては、Model_B がマンション、Model_C が工場のデータだけど、設計図、申請書などの複数書類を紐づけるやり方は Model_A と同じでよい)
つまり、Document 側からは、複数のテーブル相手に1対N のリレーションで紐づけられるようなものです。
このような設計方法にセオリーみたいなのはありますか?
思いついたこと
一つの方法(※)は、documents テーブルにカラムを追加するやり方です。
SELECT * FROM DOCUMENTS; id | model_a_id | model_b_id | model_c_id | summary | deleted_at | created_at | updated_at ----+------------+------------+------------+---------+------------+------------+------------
こんな感じです。model_a_id、model_b_id、model_c_id の not null 制約は外します
Model_*が増えるたびに、テーブルにカラムを追加してしていかなければならないので、現実的にはModel_*がどこまで増えるのかの、見通しを考える必要があります。
他方、現状の変更が楽そうな気がしてます。
つぎの方法は、中間テーブル(っぽいもの)をつくるやり方です。
N対N そのものではないのでまだ具体的な実現方法は考えてません。(Active Storage が参考になるかな?程度)
該当のソースコード
上記(※)について、Ruby on Rails の場合でどうすればいいのかわからないところ(?の部分)を掲載します
これが
ruby
1class Document < ApplicationRecord 2 belongs_to :model_a 3 has_one_attached :file 4end 5 6class ModelA < ApplicationRecord 7 has_many :documents, dependent: :destroy 8end
こう?
ruby
1class Document < ApplicationRecord 2 belongs_to :model_a (?) 3 belongs_to :model_b (?) 4 belongs_to :model_c (?) 5 has_one_attached :file 6end 7 8class ModelA < ApplicationRecord 9 has_many :documents, dependent: :destroy 10end 11class ModelB < ApplicationRecord 12 has_many :documents, dependent: :destroy 13end 14class ModelC < ApplicationRecord 15 has_many :documents, dependent: :destroy 16end
その他
回答としては、この設計方法自体よくないから破棄しなさい、というのでも結構です。(その場合、その回答にたくさんグッドが集まれば、いかに自分の質問が道から外れてるかがわかるので)
回答2件
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。