Один из множества сущностей - PullRequest
0 голосов
/ 11 октября 2018

В Symfony 4 у меня есть объект (адрес), который может быть связан с ONE из многих объектов: например, учетные записи, контакты, сотрудники .. и т. Д.

Я, по сути, хочув Address есть столбцы "entity_type" и "entity_id", но я не уверен, что это лучший способ продолжить, так как я все еще хотел бы иметь возможность использовать формы ... и т. д.

Ответы [ 2 ]

0 голосов
/ 11 октября 2018

Вы можете думать о своем отношении к другой стороне.

У учетной записи может быть много адресов.Контакт может иметь много адресов.У сотрудника может быть много адресов.

Это однонаправленное отношение «многие ко многим».

Вы можете построить отношение в целевом объекте, а не в адресном.

class Accounts
{
    // ...

    /*
     * @ORM\ManyToMany(targetEntity="Address")
     * @ORM\JoinTable
     * (
     *     name="accounts_addresses",
     *     joinColumns=
     *     {
     *         @ORM\JoinColumn(name="account_id", referencedColumnName="id")
     *     },
     *     inverseJoinColumns=
     *     {
     *         @ORM\JoinColumn(name="address_id", referencedColumnName="id", unique=true)
     *     }
     * )
     */
    private $addresses;

    // ...
}

// And so on for the others entities

Это создаст таблицу отношений в вашей базе данных с уникальным ограничением на внешний ключ address_id.

Для получения дополнительной информации посмотрите this

0 голосов
/ 11 октября 2018

Да, вы могли бы сделать это.Но это ограничит возможности совместного использования одного адреса с несколькими объектами, такими как contacts, employees и т. Д. (Если только не дублируется запись).Однако, если одна адресная запись никогда не разделяет несколько сущностей, вы можете пойти дальше и сделать это.

Как насчет третьей таблицы, которая содержит отображение между address и employees, contacts и так далее?Скажем, новая таблица с именем entity_address, структура будет выглядеть следующим образом:

  • id
  • entity_id
  • entity_name
  • address_id (foreignключ к столбцу id таблицы адресов)

Лично я предпочитаю этот подход вместо таблицы address с entity_id и entity_name по причине, упомянутой в первом абзаце,

Сказав, что у кого-то еще может быть другой подход.

В любом случае, рад помочь вам :)

...