красноречивые отношения 3 модели

У меня есть проект Laravel 5.4, где представлены некоторые из моделей: клиент, владелец, Работник, Банка (на самом деле это банковский счет, но я выбрал банк для упрощения именования при построении отношений с внешними ключами).

Теперь вот несколько фактов:

  • у каждого клиента может быть много банков (банковских счетов).
  • у каждого владельца может быть много банков (банковских счетов).
  • каждый сотрудник может иметь много банков (банковских счетов).
  • каждый банк (счет) может иметь только одного [либо клиента, либо владельца, либо сотрудника]

Каков наилучший способ построить таблицы и отношения.
Я думал о следующем:

Таблицы:

  • клиенты: id, bank_id, другие поля …
  • владельцев: id, bank_id, другие поля …
  • сотрудники: id, bank_id, другие поля …
  • банки: id, client_id, owner_id, employee_id, другие поля …

Модельные Отношения

  • Клиент имеет много банков и банковские белоги для клиента [сделано в соответствии с инструкциями Laravel]
  • Владелец имеет Множество Банков и Банковских Белогов
  • У сотрудника есть много банков и банковских вкладчиков.

Теперь при создании Bank Blade View Forms (Создать / Обновить)
Должен ли я иметь выпадающее меню, например принадлежит поле, имеющее параметры клиента, владельца, сотрудника — тогда, соответственно, я могу отфильтровать одну из трех таблиц, чтобы выбрать идентификатор держатель банковского счета, чтобы выделить его.

Недостаток:

каждый банк будет иметь только активный внешний ключ — одновременно — для одной из 3 таблиц, например client_id = 36, а два других всегда имеют значение 0, например owner_id = 0 & employee_id = 0)

Это лучший способ построения отношений или есть другой лучший способ? Пожалуйста, предоставьте форму просмотра лезвий для банков, если это возможно.

2

Решение

Выглядит как отличный кандидат на полиморфные отношения.

Структура вашей таблицы будет выглядеть примерно так:

  • клиенты: id, другие поля …
  • владельцев: id, другие поля …
  • сотрудники: id, другие поля …
  • банки: id, bankable_id, bankable_type, другие поля …

Основным отличием от предложенной вами структуры является тот факт, что мы не указываем банк в таблице клиентов, владельцев или сотрудников (поскольку их может быть несколько). Вместо этого мы указываем, к какому типу пользователей относится банк, используя bankable_id и bankable_type.

Затем в каждой из ваших трех пользовательских моделей; клиенты, владельцы и сотрудники, у вас есть следующее (может быть, лучше всего это указать):

public function banks()
{
return $this->morphMany('App\Bank', 'bankable');
}

В модели ваших банков вы можете иметь:

public function bankable()
{
return $this->morphTo();
}

Который вернет пользователя (модель клиента, владельца или сотрудника), которому принадлежит банк.

1

Другие решения

Это отношение подойдет Полиморфная связь.

Вы можете сделать так, чтобы ваши банковские счета относились к другим отношениям, подобным этому.

class BankAccount extends Model
{
public function accountOwner()
{
return $this->morphTo();
}
}

class Client extends Model
{
public function bankAccount()
{
return $this->morphMany('BankAccount', 'bankAccount');
}
}

Обратите внимание, что я использовал имя BankAccount потому что я действительно рекомендую использовать имя, которое конкретно упоминает, что оно представляет. В будущем вы или другой разработчик можете запутаться в том, что «Банк» означает «Банковский счет». И вам также следует подумать о том, что бы вы сделали, если бы решили добавить банки в свою модель, чтобы каждая учетная запись принадлежала «банку».

Очевидным недостатком полиморфных отношений является тот факт, что вы не можете иметь физические внешние ключи в таблицах базы данных.

0

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector