Rails — большие и распределенные таблицы

Я относительно новичок в Rails.

У меня есть модель пользователя через Devise. Мне интересно, эффективнее ли иметь все дополнительные поля, которые мне нужны для пользователя, в отдельной модели профиля.

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

Может ли кто-нибудь рассказать о преимуществах и недостатках создания отношения has_one, особенно с точки зрения производительности.


person alik    schedule 28.07.2011    source источник


Ответы (1)


Я также относительно новичок в Rails, но это мой взгляд...

Я думаю, преимущества ассоциаций в Rails довольно очевидны. В этом конкретном случае я думаю, что вы можете пойти в любом случае. Вот некоторые вещи, которые следует учитывать...

Если вы используете отношение has_one, вы должны помнить, что когда вы ссылаетесь на профиль, вы получите что-то похожее на это:

user = User.first

puts user.profile.first_name
puts user.profile.age

Достаточно просто, но если вам нужно что-то вроде user.first_name, вам нужно делегировать этот метод модели Profile. Это все вопрос предпочтений.

person don_solo    schedule 29.07.2011
comment
ActiveRecord относительно умен в том, что он не извлекает ассоциации, если в этом нет необходимости, и кэширует эти данные. Другой способ думать об этом состоит в том, что если у вас есть все дополнительные данные в вашей пользовательской таблице, то доступ к этим данным и их запрос КАЖДЫЙ раз, когда кто-то пытается войти в систему. По моему опыту, наличие всего этого в пользовательской таблице тормозит ваше приложение гораздо больше, чем ассоциации. Кроме того, если вы ссылаетесь на все данные, насколько важны 75 000 объектов с удвоенной памятью по сравнению со 150 000 объектов с 1/2 памяти. - person rmw; 10.08.2011