jazzus

Таблица users содержит только поля пользователей.
Таблица companies содержит только поля компаний и + поле user_id для связи с пользователями.
Юзеров связываем с компаниями c помощью связи hasMany (имеет много). Т.к. пользователь может иметь много компаний. Если непонятно гугли hasMany.
Объявление публикует юзер, делаешь поле в форме - "От компании" и выбор компаний пользователя из списка.
Таким образом у тебя пользователь может публиковать и от себя, как физлица, и от любой своей компании.
Ну а в самом объявлении проверяешь, заполнено ли поле "От компании" и если заполнено то показываешь данные компании.

Добавляем отношение в User

public function booksWhereHasMyComments()
{
     return $this->hasManyThrough(Book::class, Comment::class);
}

Запрашиваем

$user->booksWhereHasMyComments()
    ->with(['comments' => function ($query) use ($user) {
        $query->where('user_id', $user->id);
    }])
    ->get();

Второй вариант, без префиксов subscribe_ итак понятно, что от subscribers. И связь полиморфную, чтобы подписываться на кучу объектов с одним функционалом через трейт модели. для соцсетей актуально. В дальнейшем можно оптимизировать коунтерами итд

Вместо contacts и employees таблицы users roles(там client, employee и тд)
связующие
user_role
user_department с pivot position_id
вместо avatar_id полиморфную связь images в документации прямой пример
если есть еще files то аналогично

ответ на вопрос - да, иначе не будет работать manytomany
на комментарий
shop_user без role_shop_id
тк внезапно ролей может оказаться несколько
лучше roles perms user_role и role_perm

users
shops
roles
perms
user_shops (user_id shop_id) - manyToMany
user_roles (user_id role_id) - manyToMany
role_perms (role_id perm_id) - manyToMany