Ibatis как решать более сложные N + 1 проблема

Question

У меня есть база данных, которая похожа на следующее:

create table Store(storeId) 
create table Staff(storeId_fk, staff_id, staffName) 
create table Item(storeId_fk, itme_id, itemName) 

The Store таблица является большим.

И я создать следующий Java Bean

public class Store 
{ 
    List<Staff> myStaff 
    List<Item> myItem 

    .... 
} 

public class Staff 
{ 
    ... 
} 

public class Item 
{ 
    ... 
} 

Мой вопрос заключается в том, как я могу использовать результирующую карту Ibatis на ЭФФЕКТИВНО карту из таблиц в объект Java?

Я пробовал:

<resultMap id="storemap" class="my.example.Store"> 
    <result property="myStaff" resultMap="staffMap"/> 
    <result property="myItem" result="itemMap"/> 
</resultMap> 

(other maps omitted) 

Но это слишком медленно, так как таблица магазин ОЧЕНЬ ОЧЕНЬ большой.

Я пытался следовать примеру в руководстве для разработчиков Клинтона для N + 1 решение, но я не могу деформироваться мой взгляд вокруг, как использовать «GroupBy» для объекта с 2 списка ...

Любая помощь оценивается!

Answer 1

Когда вы начинаете хотеть загружать график объектов, вы начинаете понимать, почему iBatis не является ORM, а просто объектом mapper. Вы правы, что рецепт загрузки отношения в сопоставлении (исключая проблему N + 1) с функцией groupBy от iBatis трудно обобщить для вашего сценария. Я думаю, это можно сделать, но я бы не стал беспокоиться.

Обычно один реализует какую-либо ленивую загрузку здесь или загружает явно связанные объекты. В любом случае, я не уверен, какова ваша цель. Вы говорите: «Стол магазина ОЧЕНЬ ОЧЕНЬ большой». Теперь вы собираетесь загружать многие объекты Store? Вам действительно нужны связанные объекты? Задайте себе (при проектировании с iBatis), какой будет идеальный SQL для выполнения.

И не забывайте, что могут быть разные сценарии для работы с вашими объектами, и не обязательно все они должны использовать одни и те же сопоставления.

Например, часто используются два типа прецедентов, связанных с объектами Store: в первом типе требуется загрузить полный «граф объектов», но только для одного (или нескольких) корневых объектов (один Store); в другом типе нужно загрузить много «Магазинов» (со связанными данными), но только для некоторых списков или отчетов. Затем вы можете делать разные вещи в каждом сценарии: во-первых, один загружает полный объект со связанными объектами (возможно, с ленивой загрузкой, без особого беспокойства по поводу проблемы N + 1); во втором, на самом деле не загружается полный графический объект Store, а только некоторый фиктивный объект StoreWithExtraData DTO (возможно, даже простой HashMap!), который соответствует строке списка - и это можно сделать в iBatis, hoc SQL-запрос и сопоставление.