@BatchFetch type JOIN - PullRequest
       2

@BatchFetch type JOIN

0 голосов
/ 30 мая 2019

Я запутался в этой аннотации для поля сущности, которое имеет тип другой сущности:

@BatchFetch(value = BatchFetchType.JOIN)

В документах EclipseLink для BatchFetch они объясняют это следующим образом:

Например, рассмотрим объект с таблицей EMPLOYEE и PHONE в какой телефон имеет внешний ключ к сотруднику. По умолчанию чтение списка адресов сотрудников по умолчанию требует n запросов, для каждого адрес сотрудника. При пакетной загрузке вы используете один запрос для всех адреса.

но я не совсем понимаю смысл указания BatchFetchType.JOIN. Я имею в виду, BatchFetch не выполняет объединение в тот момент, когда он получает список записей, связанных с сотрудником? Записи адреса / типа телефона извлекаются с использованием внешнего ключа, так что это само соединение, верно?
Тип BatchFetch является необязательным параметром, и для объединения указывается:

JOIN - критерии выбора исходного запроса объединяются с пакетный запрос

что это значит? Разве пакетный запрос не является самим соединением?

1 Ответ

0 голосов
/ 30 мая 2019

Соединение отношения и возврат ссылочных данных с основными данными является выборочным соединением.Таким образом, запрос, который вводит 1 сотрудника с 5 телефонами, приводит к возвращению 5 строк с дублированием данных в сотруднике для расширенной строки.Когда это не так идеально, скажем, запрос более 1000 сотрудников, вы прибегаете к отдельному пакетному запросу для этих телефонных номеров.Такой запрос будет выполнен один раз, чтобы вернуть 1000 строк сотрудника, а затем выполнить второй запрос, чтобы вернуть все телефоны сотрудников, необходимые для построения считывания сотрудников.

Три типа пакетных запросов, перечисленные здесь , определяют, как будет создан этот второй пакетный запрос.Они будут работать по-разному в зависимости от настроек данных и базы данных.

  • JOIN - работает так же, как и при извлечении соединения, за исключением того, что он возвращает только данные телефона.
  • EXISTS - Этозаставляет БД выполнить начальный запрос для сотрудников, но использует данные в подзапросе Exists для извлечения телефонов.
  • IN - EclipseLink объединяет все идентификаторы или значения сотрудников, используемые для ссылки на телефоны, и использует их длянапрямую фильтруйте телефоны.

Лучший способ выяснить это - всегда попробовать его с включенным ведением журнала SQL, чтобы увидеть, что он генерирует для вашего сопоставления и запроса.Так как это параметры производительности, вы должны проверить их и записать метрики, чтобы определить, какой из них лучше всего подходит для вашего приложения по мере роста его набора данных.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...