Это скорее проблема проектирования системы, чем проблема реализации. Как сказал @Gary, вы можете использовать Inheritance Mapping , которая может иметь Проблемы с производительностью , я бы скорее предложил переосмыслить вашу схему и использовать методы нормализации базы данных, чтобы разбить ваши данные в более управляемые сущности.
Вы можете иметь сущность пользователя:
/**
* @ORM\Entity(repositoryClass="App\Repository\UserRepository")
* @UniqueEntity("email", message="Email already in use")
* @ORM\HasLifecycleCallbacks
* @Table(name="users")
*/
class User implements UserInterface
{
/* variables + getter & setter */
/**
* One user has many attibute data. This is the inverse side.
* @OneToMany(targetEntity="UserData", mappedBy="data")
*/
private $data;
}
С другой сущностью UserData с отношением OneToMany:
/**
* @ORM\Entity(repositoryClass="App\Repository\UserDataRepository")
* @Table(name="user_data")
*/
class UserData
{
/* variables + getter & setter */
@ORM\Id()
private $id;
/**
* Many features have one product. This is the owning side.
* @ManyToOne(targetEntity="User", inversedBy="data")
* @JoinColumn(name="user_id", referencedColumnName="id")
*/
private $user;
/**
* @ORM\Column(type="string")
*/
private $attribute;
/*
* @ORM\Column(name="value", type="object")
*/
private $value;
}
Теперь вы можете иметь список пользователей атрибуты, не требующие указания c структуры для каждой роли. Он масштабируемый и произвольный.
Вы также можете определить ту же связь с объектами TeacherData, StudentData или UserProfile с внешними ключами и ветвить логи приложения c в соответствии с ролями. Ключ состоит в том, чтобы разбить данные на отдельные домены и хранить общие данные в одной таблице. Загружайте связанные данные, запрашивая связанные объекты, это повышает удобочитаемость и упрощает разбивку сложной структуры на управляемую кодовую базу.