как моделировать отношения многих ко многим

Question

Вот сценарий, Статьи имеют много комментариев Пользователи могут написать много комментариев для многих статей

Таблица комментариев содержит оба

user_id
article_id

как внешние ключи

Мои модели настроены так

class User < ActiveRecord::Base
  has_many :comments
  has_many :articles, :through => :comments

class Article < ActiveRecord::Base
  has_many :comments
  has_many :users, :through => :comments

class Comment < ActiveRecord::Base
  belongs_to :users
  belongs_to :articles

Мой route.rb имеет следующий код

  map.resources :articles, :has_many => :comments  
  map.resources :users, :has_many => :comments

, который производит следующие маршруты

new_article_comment
edit_article_comment
new_user_comment
edit_user_comment
etc...

Это не то, что я хочу (по крайней мере, не то, что я думаю, что я хочу), так как комментарии всегда должны быть связаны с пользователями и статьями, как я могу получить маршрут, как это

new_user_article_comment
edit_user_article_comment

Тогда я мог бы просто сделать

new_user_article_comment_path([@user, @article])

для создания нового комментария

Answer 1

Вы создали циклическую схему базы данных. Не очень рекомендуется.

Модель данных должна выглядеть следующим образом:

class User < ActiveRecord::Base
  has_many :comments

class Article < ActiveRecord::Base
  has_many :comments

class Comment < ActiveRecord::Base
  belongs_to :user
  belongs_to :article

И базовая маршрутизация:

map.resources :articles do |articles|
  articles.resources :comments
end

А затем решите, что еще вам нужно, чтобы он соответствовал вашим требованиям.

Answer 2

Возможно, вы могли бы сделать это, используя вложенные маршруты. В этой статье есть хороший пример того, как это сделать:

http://weblog.jamisbuck.org/2007/2/5/nesting-resources

Обратите внимание, что в статье говорится "не делай этого":

«Правило большого пальца: ресурсы никогда не должны быть вложенным на глубину более 1 уровня. Коллекция, возможно, должна быть ограничена его родитель, но конкретный член может всегда доступны напрямую по идентификатору, и не должны нуждаться в определении объема работ (если только почему-то идентификатор не уникален). "

Однако , приведенная выше цитата не относится к вашему действию, а также к другим случаям, когда уникальный идентификатор (пока) недоступен, поскольку у вас еще нет уникального идентификатора комментарий, а также идентификатор пользователя и статьи абсолютно необходимы. Комментарий на той же странице предлагает эту квалификацию:

Тийс ван дер Фоссен сказал ... «Мы изобрели второе эмпирическое правило; ресурсы должны быть вложены только для действия, которые действительно нуждаются в родительском идентификаторе (например, «index», «new» и «create»). Мы начали использовать это для приложение с моделью данных, которая почти полностью иерархический, за исключением где это не так и, кажется, работает очень хорошо. Зачем держать родителя ресурс в URL, когда структура не является строго иерархическим? "