Дилемма о Rails has_many: сквозная связь разных типов - PullRequest
0 голосов
/ 30 апреля 2011

Я столкнулся с дилеммой по поводу использования has_many: through.

Предположим, я пытаюсь смоделировать меню ресторана через Rails.И предположим, что в этом ресторане может быть несколько разных видов меню, в зависимости от вида еды.

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

Очевидно, у нас должно быть меню и класс еды, нам также нужна таблица соединений для них, чтобы указать различные меню.и отношения HABTM между ними.

Но как нам иметь дело с типом еды?
Обратите внимание, что тип еды принадлежит_ ко многим продуктам, но принадлежит только одному меню.Я чувствую, что добавление его в предыдущую таблицу соединений было бы неэффективным.

В этом примере, я думаю, я бы решил, создав новую модель MealType и написав, что Food has_many: food_types,: through еды.

Затем обновите модель меню, поскольку меню может иметь только один тип питания.Это означает, что у меня будет отношение has_one с MealTypes для каждого меню.Кратко:

Класс еды:

has_many Menus, :through menu_food_join_table  
has_many MealTypes, :through meals  

Класс меню:

has_many Foods, :through menu_food_join_table  
has_one MealType  

Класс MealType:

belongs_to Foods, :through meals  
belongs_to Menus  

И вот я дошел до своегоДилемма: этот код воняет, по крайней мере, для меня.Не представляется практичным иметь несколько таблиц для простых отношений, как это.И я не думаю, что мне следует добавлять поле MealType в Foods, так как некоторые продукты могут быть на несколько приемов пищи (например, кока-кола).

Также я не должен добавлять MealType в Menus, так как я хочу иметь возможностьРазделите продукты также по типам еды (например, если бы я хотел показать только те продукты, которые разрешены при определенных приемах пищи).

Что бы вы сделали в этом случае?Должен признаться, у меня нет большого опыта в разработке ОО, поэтому я пришел сюда.


Мое окончательное решение

Вот решениеЯ решил решить эту проблему:

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

Затем я добавил отношение «есть много блюд» к модели «Питание» через таблицу соединений.Единственная вещь в базе данных Еды - это типы блюд, которые я хочу приготовить (завтрак, обед, ужин и т. Д.).У еды есть много еды через одну и ту же таблицу соединений.

У меня все еще есть контроллер и представление Menu, которые я использую для создания MenuFactory.

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

1 Ответ

0 голосов
/ 30 апреля 2011

Вы, кажется, слишком усложняете вещи. У вас есть один ресторан, тогда у него есть одно меню на завтрак, одно меню на обед, одно меню на ужин. Это всего лишь три меню - я не думаю, что вам вообще нужно моделировать тип.

Так что на самом деле вам просто нужно

Меню: has_many menu_items

MenuItem: принадлежит к меню

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

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

...