Ключевая идея здесь заключается в том, что у вопроса есть один задающий вопрос, но несколько последователей.Работая с моделью данных, в которой вы представляете все в виде таблиц, вы должны создать следующую структуру:
USER (id(PK), name, ...)
QUESTION (id(PK), title, text, author(FK to USER))
FOLLOW (userid(FK to USER), questionid (FK to QUESTION))
Поскольку отношение автора одно к многим, от пользователя USER к ВОПРОСУ, и много ко многим между пользователем USER.и ВОПРОС.Таблица FOLLOW - это обычная таблица соединений.
Теперь, когда ORM с JPA, все становится интересным.Да, вы можете избежать явного создания класса Follow, сохранив список вопросов для каждого пользователя.Вам понадобятся @ManyToMany и @JoinTable.Является ли это более эффективным, чем явный класс Follow, возможно, с двумя @ManyToOne с или двумя @OneToMany с?Я не совсем уверен, но я подозреваю, что, поскольку JPA - это просто спецификация и может быть несколько реализаций, возможно, что разные реализации могут отличаться по производительности.Конечно, вы можете попробовать оба способа, написать несколько запросов и посмотреть на сгенерированный SQL.Если вы уже знакомы с методами эффективной стратегии извлечения и у вас есть другие навыки, такие как избегание проблемы выбора n + 1, тогда вы можете найти это забавное упражнение.
Конечно, избегание класса модели для таблицы соединений - это больше ORM-иш, так как вы можете просто сосредоточиться на уровне объекта и не слишком беспокоиться о базовых таблицах.Но хорошо знать, что происходит за кулисами, так как вам все еще нужно понять, как сделать эффективную выборку и как избежать n + 1 выбора и т. Д.
Кроме того, если ваше последующее отношение имеет атрибуты своегоСобственно, вам может показаться, что явный класс модели Follow является хорошей идеей.
Суть в том, что модель «многие ко многим» без модели Follow, вероятно, самая чистая, но выберите то, что лучше всего читатьдля вас, и сделайте некоторое профилирование, если у вас есть какие-либо сомнения.Я верю, что в конечном итоге только просмотр сгенерированного SQL скажет вам то, что вы хотите знать, потому что JPA не определяет SQL.И реализации JPA тоже могут быть довольно умными.