Варианты Rails Association - PullRequest
       30

Варианты Rails Association

0 голосов
/ 22 февраля 2012

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

Я создаю приложение для групп для отображения предстоящих событий.

Есть несколько важных факторов

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

В настоящее время, как это настроено:

class Event < ActiveRecord::Base    
  belongs_to :venue
  scope :upcoming, where('date >= ?', Date.today)
end  

class Venue < ActiveRecord::Base
  has_many :events
  accepts_nested_attributes_for :events
end

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

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

Становится немного сложнее, когда я начинаю думать о том, как наилучшим образом сделать так, чтобы художники делились событиями, и поддерживать конкретные подробности о событиях, которые относятся только к этому артисту. Я мог бы просто рассматривать каждое событие как отдельное событие, и это было бы легко, но тогда я не уверен, как я мог бы сказать, что этот артист выступает с этими артистами в эту дату, кроме артистов, вводящих эти имена непосредственно в 1 поле. Я также теряю магию ActiveRecords в отношении того, какие артисты выступали с какими другими артистами, где и т. Д.

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

Не могли бы вы предложить несколько моделей или есть ли лучший способ для меня связать группы, играющие несколько событий, вместе, чем создать детальную модель события, связывающуюся с 1 основным событием, которое разделяют несколько артистов? Должен ли я просто создать некоторый тип уникального идентификатора события в таблице событий, чтобы я воспринимал событие с другим идентификатором как то же событие, которое играет другая группа? Единственная проблема, с которой я сталкиваюсь, это то, что я собираюсь удвоить большую часть этих данных, которые есть в моей базе данных ... Я, по сути, хочу, чтобы при просмотре данных о событиях сказать «хорошо» в эту дату, когда артист играет это шоу, в этом месте, с другими группами, которым не нужно просто делать колонку "other_artists", где группы просто перечисляют исполнителей, с которыми они выступают.

извините, я надеюсь, что это имеет смысл ... заранее спасибо за любой совет!

1 Ответ

0 голосов
/ 22 февраля 2012

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

Я бы создал класс «Бронирование», который специально связывает одного артиста с одним событием.Это бронирование будет хорошим местом для проведения каких-либо особых требований или специальных мероприятий для артиста, играющего на этом мероприятии.Использование отношения ActiveRecord «has_many: through» сделает это очень прямым и даст вам большую гибкость в том, как вы можете запрашивать данные.Вот как я бы это сделал:

class Event < ActiveRecord::Base    
  belongs_to :venue
  has_many :artists, :through => :bookings
  scope :upcoming, where('date >= ?', Date.today)
end  

class Venue < ActiveRecord::Base
  has_many :events
  accepts_nested_attributes_for :events
end

class Artist < ActiveRecord::Base
  has_many :events, :through => :bookings
end

class Booking < ActiveRecord::Base
  belongs_to :artist
  belongs_to :event
  attr_accessible :special_requirements, :special_arrangements
end

Некоторые примеры гибкости, которую вы получаете при запросе данных с помощью этих отношений:

 @venue.events
 @venue.events.where(:id => specific_event.id).first.artists
 @event.artists
 @artist.events
 @event.bookings each do |b|
   b.artist
   b.special_requirements
 end

Надеюсь, это поможет.

...