Наследование доктрины, базовый класс и два подтипа

Мне нужно обработать 3 объекта, которые охватывают одну и ту же таблицу пользователей:

  • User: охватывает класс пользователей и участвует в некоторых службах аутентификации / проверки.

  • Driver: расширяет User и относится к некоторым другим таблицам. Также участвует в разных сервисах.

  • Passenger: расширяет User и относится к другим таблицам. Также участвует в разных сервисах.

Все записи в таблице users являются пользователями. Записи с is_driver=0 - это пассажиры, а записи с is_driver=1 - водители.

Я знаю, что могу создать сопоставленный суперкласс для таблицы пользователей, а дискриминатором будет is_driver. Таким образом, сущность "Пассажир" и "Водитель" расширили бы это. Проблема, которую я вижу, заключается в том, что я не могу создать объект User, который расширяет этот сопоставленный суперкласс, потому что у него нет дискриминатора, любая запись является пользователем.

Есть существующая база данных, и я переношу проект, есть столбец is_driver, который различает, является ли пользователь водителем или пассажиром (крошечный int 0 или 1). Теперь я хотел бы иметь 3 объекта.

  • User: общий (любая строка)
  • Driver: те строки с is_driver = 1
  • Passenger: те строки с is_driver = 0

В идеале все должно быть каким-то образом прикреплено в ORM к таблице users, а водитель и пассажир также должны быть отдельно связаны с разными объектами.

Я не могу понять твой вопрос. Является ли этот столбец is_driver существующим столбцом базы данных, который необходимо перенести в свое приложение? Если да, каково значение дискриминатора для User? null? Или почему бы вам не использовать дискриминатор type с возможными значениями, например, user|driver|passenger?

Nicolai Fröhlich 31.10.2018 14:55

Извините, если я не объяснил это так хорошо, как хотелось бы. Пожалуйста, проверьте правки.

javier_domenech 31.10.2018 15:38

Единственное, что я могу придумать, - это использовать наследование для Driver & Passenger, но User - это просто сущность, которая сопоставляется с той же таблицей. Все они могут иметь общий интерфейс, чтобы прояснить в коде, что когда вы ожидаете UserInterface (не из соображений безопасности, а ваш собственный), он может быть пользователем, водителем или пассажиром. Однако это может привести к несогласованности данных и может вообще не работать. Если никакое другое приложение не записывает в базу данных, вы также можете разделить таблицу: например, иметь пользовательскую таблицу со связанной таблицей (водитель / пассажир), которая содержит столбцы user_id и is_driver.

dbrumann 31.10.2018 17:05

Вы думали об этом иначе? Просто имейте класс User, который сопоставляется с базой данных, и всякий раз, когда вы хотите узнать, являются ли они водителем / пассажиром, или вы не вызываете isDriver() и isPassenger() для пользователя? Так что, по сути, водитель и пассажир вообще не должны быть отдельными классами. Однако в зависимости от вашего существующего кода это может означать обновление большого количества кода.

dbrumann 31.10.2018 17:09

Может, но водитель связан с автомобилем, пассажир связан с компанией и т. д. Они действительно разные, и я хотел бы сопоставить их отдельно с этими отношениями в ORM

javier_domenech 31.10.2018 17:11
1
5
59
0

Другие вопросы по теме