VV
А чем ваш случай особенный?
Size: a a a
2020 July 23
v.
тем что записей SocialVideos несколько десятков тысяч, у модели уже есть свои связи, social_videos достаточно редко будут прикрепляться к Offer а значит в колонке offer_id будет куча nil
DM
Добрый день. Вопрос больше по Rails, но также к теме правильной организации связей классов, может будут желающие посоветовать.
Есть модели
Как определиться с вариантом архитектуры из этих двух:
1. добавить колонку
потом забирать id-шники и находить нужные записи
2. сделать связь через модель
тогда можно будет забирать как
Есть модели
Offer и SocialVideo
Нужна возможность к Offer прикреплять SocialVideo. Только для показа во вьюхе юзеру.Как определиться с вариантом архитектуры из этих двух:
1. добавить колонку
Offer.social_videos_ids и serialize :social_videos сохранит id-шники в yaml форматепотом забирать id-шники и находить нужные записи
2. сделать связь через модель
Favorite
выступает в роли соединительной таблицы с полиморфными связямиfavoritor_id, favoritor_type, favoritable_id, favoritable_typeизначально была для 'лайков'
тогда можно будет забирать как
Offer.favoritesоба варианта прохладные какие то
DM
1 ваще сразу можно выкинуть, какой то костыль, 2 а тут проще сделать обычную has_many как выше предложили
v.
есть сделаю колонку SocialVideo.offer_id и has_many связь, то невозможно будет одни и те же SocialVideos прикреплять к разным Offer. А это будет нужно. Значит опять возвращаемся к соединительной таблице?
v.
в моем случае through what ?
VV
есть сделаю колонку SocialVideo.offer_id и has_many связь, то невозможно будет одни и те же SocialVideos прикреплять к разным Offer. А это будет нужно. Значит опять возвращаемся к соединительной таблице?
Да, если одно видео можно цеплять к нескольким офферам, то offer_social_videos таблица с ключами offer_id, social_video_id
VV
И связь, как Эдем написал
v.
Про лайки не понял, какая связь
ну вот, значит возвращаемся к первоначальному
если у меня есть модель Favorite:
будут добавляться записи вида
если у меня есть модель Favorite:
Favoriteимеет ли смысл не создавать отдельную таблицу offer_social_videos, a использовать существующую favorites ?
favoritor_id, favoritor_type, favoritable_id, favoritable_type
будут добавляться записи вида
favoritor_id: 1111, favoritor_type: 'Offer', favoritable_id: 2222, favoritable_type: 'SocialVideo'и связи:
Offer
has_many :social_videos, through: favorite
SocialVideo
belongs_to :offer
VV
Развивая вашу идею. Сделайте эту таблицу для связи вообще всех пар моделей, где нужна many-to-many связь :)
v.
Сейчас в таблице favorites записи вида
favoritor_id: 1111, favoritor_type: 'User', favoritable_id: 2222, favoritable_type: 'SocialVideo'
favoritor_id: 3333, favoritor_type: 'User', favoritable_id: 4444, favoritable_type: 'Editor'
Это и имелось в виду, когда писал, что используется для 'лайков'
favoritor_id: 1111, favoritor_type: 'User', favoritable_id: 2222, favoritable_type: 'SocialVideo'
favoritor_id: 3333, favoritor_type: 'User', favoritable_id: 4444, favoritable_type: 'Editor'
Это и имелось в виду, когда писал, что используется для 'лайков'
VV
Ну я понял, вы на таблицах решили сэкономить
VV
А зачем?
v.
Развивая вашу идею. Сделайте эту таблицу для связи вообще всех пар моделей, где нужна many-to-many связь :)
Ну вот я собственно и советуюсь чтоб понимать на сколько это хорошо или плохо с точки зрения других. На мой взгляд казалось достаточно логично иметь favorites для каких то моделей, к которым нужно присоединить другие many to many