В использовании связи HasOne есть архитектурный нюанс, который многие не учитывают при построении таблиц и формировании отношения HasOne в laravel. А именно: в некоторых случаях нужно явно гарантировать использование связи HasOne на уровне БД.
Например, у нас есть таблица users и соответственно модель User. Так сложилось, что бизнес логика выстрена вокруг пользователей и совершается много действий относительно пользователей и мы вынуждены были создать отдельную таблицу, например, с настройками пользователей - user_settings.
Естественно, это будет HasOne т.к. сложно себе представить сценарии, в которых одному пользователю нужно будет иметь больше одной записи настроек!
Но, какие ключевые поля будут в этой таблице? В большиснвте случаев, это было бы что-то типа такого:
| id | integer |
primary |
| user_id | unsigned integer | foreign |
| ...other fields | ||
В этом случае, мы не можем гарантировать строго одну запись для каждого пользователя.
Поэтому правильно было бы сделать так:
| user_id | integer | primary, foreign |
| ...other fields |
Laravel подобных рекомендаций не дает (и не должен), но такой подход гарантирует отсутсвие дублей и поиска непредвиденных проблем в будущем.
Что касается остальных случаев, можно придерживаться классической схемы с id как PRIMARY.
Например, у нас есть Task Manager и решили сделать для задач(tasks) напоминания(reminders). В таком случае можно оставить id PRIMARY т.к. если сегодня мы решили, что у задач может быть только одно напоминание (HasOne), то в будущем мы можем изменить на множественные напоминания (HasMany).
Важно такие моменты предусматривать в проектировании приложений!