Таблица articlesauthorslink является стандартным способом реализации соотношения много ко многим.

join'ами или select'ами можешь выбирать что угодно, в чем собственно проблема?

Как должны выглядеть эти 3 Enity? 3 ли? Есть еще такой момент, что мне нужно избегать аннотации @OneToMany. Я во всем этом запутался, поэтому прошу если не разжевать, то хотя бы дать мне ссылку на годный туториал по связям и использовании такой таблицы.

Оно?

http://viralpatel.net/blogs/hibernate-many-to-many-annotation-mapping-tutorial/

Нет, мне нужно избегать аннотаций @ManyToMany и @OneToMany при помощи этой линк таблицы. Я поначалу хотел отделаться простыми запросами к базе, но нужно использовать маппинг этой таблицы.

Нет, мне нужно избегать аннотаций @ManyToMany

То, что ты описал в заголовке темя и есть отношением много-ко-многим. Стандартной реализацией такого отношения средствами sql является создание третей - связующей таблицы. Например, если между таблицами A и B отношение много-ко-многим, то создается третья таблица A_B, в которой поля id - идентификатор записи, a_id - внешний ключ (соответствует A.id) и b_id - внешний ключ (соответствует B.id).

В твоем случае выбор, например, авторов и соответствующих им книг осуществляется конструкцией вида

SELECT authors.login, articles.title
FROM authors INNER JOIN articlesauthorslink ON authors.id = articlesauthorslink.author INNER JOIN articles ON articles.id = articlesauthorslink.article;

Давай ты признаешься зачем тебе их избегать для начала?

Ага! Вроде бы дошло, когда за дело возьмусь — станет ясно, дошло или нет. ☺

Спасибо.

Человек, который их порекомендовал (читай приказал) избегать сетует на скорость получения данных из базы.

Потому что по дефолту там lazy, что кстати то что надо, когда выгребаешь только первый обьект. А потом тебе внезапно нужны остальные и ты делаешь еще запросы.

Некоторые двоечники стремглав делают eager и получают большие датасеты когда им не надо. А по нормальному нужно использовать на уровне JPQL запрос типа FETCH JOIN в тех случаях когда точно нужно потом будет получить связанный обьект, он сразу выберет все вместе. Но опять же, только когда это именно то что нужно

Кинь в меня туториалом, в котором нормально объясняется про все эти *-To-* отношения в реляционных БД. Пожалуйста. Я в этом очень хреново плаваю, но очень хочется это исправить.

Вообще то есть обычный, тот который самый главный Java EE 6 Tutorial PDF, но понятно вот тут

http://en.wikibooks.org/wiki/Java_Persistence

Спасибо. Но до меня пока не дошло как совет Genuine использовать вместе с entity, которая будет маппингом articlesauthorslink? Т.е. как должны выглядеть ArticlesAuthorsLinkEntity, ArticlesEntity и AuthorsEntity? С последними двумя все ясно кроме того, как туда вписать ArticlesAuthorsLinkEntity, а точнее, наверное, коллекцию ArticlesAuthorsLinkEntity.

ArticlesAuthorsLinkEntity не должно быть вообще. Почитайте о @ManyToMany. Вкратце, у Article есть поле authors со списком из других сущностей с кучей аннотаций включая ManyToMany, которые все конфигурируют. У Author поле с обратным списком связей articles с аннотацией ManyToMany с атрибутом mappedBy=«authors», которое указывает на названия поля с конфигураций.

Тоесть как бы конфигурация только в одной сущности, а в другой сущности просто ссылка на конфигурацию.

Но мне нужно это реализовать без аннотаций @ManyToMany и с ArticlesAuthorsLinkEntity. %)

Забей, тот твой советчик - неосилятор JPA

Ох, ладно. /me ушел читать твой викиталмуд.

Тебе на чистом JDBC надо реализовать?

Опять таки JavaEE6 Tutorial поможет тебе.

Если не понимаешь - почитай книжку Грабера по SQL - вроде достаточно хорошо разжевано.

Получается, что мы аннотацию переносим с уровня поля на уровень запроса?

Да, стратегию lazy/eager, это позволяет связать вообще все сущности в lazy bidirectional отношения. Если бы они были не lazy, то почти любой запрос загружал бы всю базу в память (при условии что оно вообще бы осилило нагенерить такой чудо-запрос). lazy - хороший default, который позволяет прозрачную навигацию по дереву обьектов в рамках транзакции. А join fetch позволяет конфигурировать выборку набора разнотипных связанных сущностей в одном запросе с целью оптимизации производительности. Но после join fetch запроса интерфейс работы с данными не меняется, просто при использовании списков связанных сущностей они уже там есть.