Способ Rails для баз данных: учетная запись person may_have (has_one?) - PullRequest
0 голосов
/ 16 марта 2012

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

Небольшой фон поможет прояснить вопрос: Я создаю веб-приложение с использованием Rails 3.2, которое помогает управлять гонками.Люди смогут создавать учетные записи (/ учетные записи пользователей), проводить гонки и управлять различными аспектами.

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

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

Я искал некоторое время, но на самом деле ненайденные решения.Я полагаю, что способ сделать это состоит в том, чтобы иметь примечание модели участников "has_one UserParticipation", которое обычно равняется нулю.

Это правильное решение?Есть ли лучший способ сделать это?

Вот небольшая диаграмма, которую я составил в Paint, чтобы кратко показать проблему: database_issue

Вопрос 2: Это немного менее важно,но я подумал, что задам его в том же вопросе, потому что я уже опубликовал соответствующий вопрос: некоторые вещи будут ссылаться на участников, есть ли причина устанавливать составной суперключ {Race_ID, Participant_Number} вместо того, чтобы всегда ссылаться на него, используя"race.participants"?(Насколько я могу судить, они будут работать очень похоже.)

Ответы [ 2 ]

1 голос
/ 16 марта 2012

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

simple erd

Некоторые пояснения по поводу пользователя до участников :

Участник будет иметь ассоциацию belongs_to :user, которая равна nil, если нет ассоциированного пользователя.

Пользователь будет иметь ассоциацию has_many :participants, что не позволяет многим участникам. Если их нет, экземпляр пользователя будет иметь user.participants равный пустому массиву.

Что касается второго вопроса, вам нужно будет использовать оба ключа, только если вы запрашиваете конкретного участника для конкретной расы, например, where participant_id = 7 and race_id = 4.

0 голосов
/ 16 марта 2012

Таким образом, в гонке много участников (некоторые из которых являются пользователями), а у участника много рас (надеюсь: -).

На мгновение вычеркивая часть вещей пользователя из картины, это простое отношение «многие ко многим», которое Rails прекрасно обрабатывает с помощью has_and_belongs_to_many как для моделей Race, так и для участников, описанных здесь http://guides.rubyonrails.org/association_basics.html#the-has_and_belongs_to_many-association. Другой альтернативой, которая не нужна в вашем случае, является has_many :through, которая создает первоклассную модель, опирающуюся на таблицу соединений. Но то, что вы описали, делает это ненужным.

Отношения между Пользователем и участником однозначные и условные. Мне не ясно, можете ли вы быть пользователем, не будучи участником, но если у вас есть пользователь, который является участником, вы хотите, чтобы они были связаны. Это :has_one отношение.

Крутая часть Rails, которую, я готов поспорить, вы ищете, заключается в том, что отношения могут быть условными, поэтому в этом случае Участник имеет пользователя__ условно. Связанный документ Rails Guide описывает, как все это определить.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...