Здравствуйте, Blazkowicz, Вы писали:

B>1) Если банально прописать маппинг many-to-one, то получается HBSubjectBean будет выбиратся в 99% случаев где он не нужен. Создавая дополнительную нагрузку на базу. Вопрос, если прописать fetch="join", получается выборка будет через джоин. Значит ли что оверхед при этом будет довольно мал. И им можно было бы принебречь?

лучше join не делать, хз, как поведёт себя БД, может справится, а может и нет

B>После этих раздумий я сделал через Ж. Благо весь проект такой и моей маленькой лажи никто не заметит.

я бы так не делал =)

B>Буду премногоблагодарен за комментарии и рекомендации как решить проблему одними только маппингами.

почему только маппингами?
я бы как раз посоветовал тюнить код выборки, т.е. для общего случая оставить lazy, а в конкретном уж разобраться так, чтобы отскакивало

B>2) Если many-to-one сделать ленивым, то в 99% оверхеда не будет. Зато проблемы начнутся в моем единственном случае. Так как выборка происходит сразу толстого списка HBPhoneCallBean, то при ленивой загрузке HBSubjectBean будет выбрана каким-нибудь тормозным способом, подозреваю что отделmным запосом на каждый HBPhoneCallBean. Что убъет производительносьт операции наповал.

как ты выбираешь "толстый список"?
например, если через Criteria, то укажи ему явно FetchMode для нужной связки