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).
