Где установить отношения внешнего ключа в приложении rails с помощью has_many через - PullRequest
0 голосов
/ 12 января 2011

Я устанавливаю простые отношения has_many через.Мне было интересно, есть ли какие-либо рекомендации, которые я должен учитывать при настройке отношений с внешним ключом.

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

Главный вопрос, который у меня возникает, - какие модели должны принадлежать пользовательской модели?Я думал, что самое простое решение - это иметь список принадлежащих пользователю.Таким образом, я могу использовать отношение has_many through, чтобы выяснить, какие элементы и какие объявления принадлежат_ каждому пользователю.

Однако мне пришло в голову, что это может оставить некоторые дыры в зависимости от того, какие рабочие процессы я хочу сделать возможными,Например, что если пользователь захочет создать группу элементов перед созданием рекламы, в которой есть эти элементы?Что если пользователь создаст объявление до того, как создаст какие-либо элементы?

Исходя из вышеизложенного, я подумал, что, возможно, я должен просто сделать рекламу, и элементы принадлежат пользователю.Если я это сделаю, есть ли какая-либо очевидная причина сделать так, чтобы листинг принадлежал пользователю?Я собирался сделать это, но каким-то образом это выглядело для меня излишним.

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

Спасибо!

1 Ответ

0 голосов
/ 12 января 2011

Я пытаюсь понять, что у вас есть:

Пользователь Объявление Вещь Листинг

Где Listing - это какая-то модель соединения, которая связывает Item с Ad.

Я не вижу много неправильных способов сделать это. Я полагаю, что наиболее нормальным способом сделать это было бы просто иметь элемент belong_to пользователя и получать через него списки и объявления. Но вы бы тоже заплатили за это как за то, что написали раздражающий код, так и за то, что вам нужно было выполнить несколько объединений, чтобы получить свои объявления.

Противоположная крайность - просто belong_to иметь пользователя. У вас есть дополнительный столбец в 2 ваших моделях, но у вас также есть гораздо более простые отношения. Вам также не придется беспокоиться о том, какие рабочие процессы разрешены вашим пользователям при разработке схемы.

Даже если вы запутались и не указали поля user_id в своих моделях, добавить эти поля не так уж сложно, используя миграцию.

...