В Laravel все в БД должно быть сущностями?

Question

[pemi]

Вот у меня есть модель User. User может иметь несколько привязок к аккаунтам соцсетей. Сайт может поддерживать пока 3 соцсети. Для привязок храню в таблице users_socials такие данные - user - service(enum) - id_in_service. Так вот, из-за того, что соцсетей мало (их всего 3) я использую enum а не создаю для каждой соцсети строку в отдельной таблице. Это правильно? Или надо создать отдельную модель Social и с помощью relations соединить соцсеть и юзера? Не накажет меня Тэйлор за это?

Answer 1

[JhaoDa]

Да, правильным будет избавиться от енумов, создать отдельную модель Social и с помощью связей соединить соцсеть и юзера.

Нет, не всё в БД должно быть сущностями, но в данном случае это удобно.

Comments

[JhaoDa]

pemi: так вас устраивает ответ или нет?

[pemi]

JhaoDa: не совсем. при связке нужно где то указаывать уникальный id пользователя в соцсети. как это сделать?

[JhaoDa]

pemi: это уже другой вопрос, который недавно задали отдельно. Раз вы решили последовать моей рекомендации и сделать сущности вместо енумов, то она вас устроила?

Answer 2

[Игорь Воротнёв]

1. Enum'ы не очень ок, не используйте их. Потом рефакторить больше гемора чем удобства / пользы от них.
2. Не все обязательно должно быть сущностями, но в основном да - так удобнее.
3. В вашем случае в самой простой реализации это связь oneToMany - User hasMany Socials / Social belongsTo User (дополнительные данные хранятся в таблице socials):

Таблица users: id | email | ...
Таблица socials:

id | user_id (foreign key) | external_social_id | title | ...

Но здесь у вас будет дублирование всех данных по каждой соцсети - начиная от поля title и далее (а что там - зависит от проекта. Вполне возможно там еще API key может быть, иконку привязать, урл и тд). Поэтому такая БД не будет адекватно нормализована. Если по соцсети у вас будет более 1 поля name/title, то разумнее делать связь manyToMany с использованием pivot.

Связь manyToMany - User belongsToMany Socials / Social belongsToMany Users (дополнительные данные расходятся по таблицам - все что уникально для Social в socials, все что касается связи - в pivot):

Таблица users: id | email | ...
Таблица socials: id | title | icon_path | ...
Таблица social_user:

social_id (foreign key) | user_id (foreign key) | external_social_id | ...

В моделях:

// User
public function social()
{
    return $this->belongsToMany(Social::class)->withPivot(['external_social_id']);
}
    
// Social
public function user()
{
    return $this->belongsToMany(User::class)->withPivot(['external_social_id']);
}

Если такая динамичная сущность связи со временем растет и усложняется, делаем из нее полноценную сущность, создавая свою модель (class SocialUser extends Pivot).