Здравствуйте! Не знал как обозвать тему поточнее, надеюсь частично суть в заголовке передал, теперь подробно:

Есть таблица_1 в БД, содержит записи, которые в проекте читаются как объекты, ну тут все как у всех :)
Есть таблица_2 с пользователями, id, name и прочее.
Задача: закрепить объект из таблицы_1 за несколькими записями из таблицы_2
При этом не хотелось бы заводить таблицу_3, для связи этих двух таблиц и вот почему, см. ниже.

Проблема в следующем:
1. Использую для выгребания данных из БД Hibernate.
2. Приложение написано с использованием Vaadin, то есть весь UI на нем.
3. Таблица_1 содержит более 1000 записей, на самом деле и больше 10000, но не суть, главное что больше 1000 точно.
Простой select from таблица_1 с некоторыми условиями аля where что-то там в этой таблице is false, может выгребать без проблем 10000+ записей и отображать их в таблице Vaadin без проблем, скорость прокрутки и отображения данных при этом отличная.
4. Как только я прикручивал (это было давно и в другом проекте) таблицу_3 для связи этих двух таблиц и делал запрос, который бы отображал записи "закрепленные" за конкретными id из таблицы_2, то есть записи конкретного пользователя, то тут начинались тормоза. Потому что, сначала мы берем объект из таблицы_1, потом проверяем по таблице_3 связь с таблицей_2 ну и тянется эта цепочка запросов. Если записей 300-400 еще ничего, но в районе 1000 начинаются тормоза и при прокрутке таблицы в UI и при первичном формировании таблицы при первой загрузке UI c таблицей Vaadin.

5. Было принято решение создать в таблице_1 текстовое поле именуемое usersIds, в котором содержится строка с перечислением id тех пользователей, которые, скажем так, закрепили за собой объект из таблицы_1. Пример данных из этого поля: 1,2,15,45,65,23,14 и т.д.
5.1 При запросе в базе выгребались все объекты из таблицы_1 и затем List<таблица_1> перебирался на наличие в этом поле айдишника того юзера, который сейчас делает запрос на отображение только тех записей за которыми "закреплен" и вываливалось в таблицу UI.

Все это мне не нравится, так как чувствую что это не правильно, не модно и т.д., но это работает, и работает быстро, в старом проекте от которого я уже отошел.
Сейчас появилась подобная задача и я не знаю, стоит ли делать точно так же или, может быть, есть какие-то наработки в этом вопросе, которые бы ускорили отображение данных в UI? Может есть кардинально другой способ, о котором я не знаю, отойти от использования промежуточной таблицы и получить приемлемую скорость? Может вообще сам Hibernate где-то подкручивается, под это дело, я с ним толком не разобрался, так как пробовал выгребать данные с помощью JDBC и получал практически такую же картину.

п.с. в классах с сущностями, я уже использую ленивую подгрузку, но в случае использования таблицы_3 все равно наблюдаются тормоза, поэтому сделал то, что в пункте 5. Настройки таблицы Vaadin такие как, первоначальная подгрузка энного кол-ва строк, буферизация строк за пределами таблицы и еще какие-то, я тоже пробовал, но это так же тормозит либо при первой загрузке либо при прокрутке, т.е. так и так тормозит.

таблица_1 это список заявок, ну можно и список счетов его назвать не суть важно это пусть будет называться
Request
с полем user_request_id (при условии, что добавили 3-ю таблицу, см.ниже)

таблица_2 пусть будет
User

таблица_3 пусть будет
User_Request
с полями request_id и user_id

один объект Request должен быть в выборке как у User'а c id 1, так и с id 3, так и у юзера с любым другим id, но, к примеру, в выборку для юзера с id = 6 он не должен попадать.

Когда делаем выборку из Request с вложенным запросом для пользователя с id=1 аля
select * from Request as r where r.id in (select request_id from User_Request as ur where ur.user_id = 1)
Вот тогда таблица Vaadin начинает тупить.
В общем, я сам, по ходу дела, туплю, запрос такого вида я, вроде как, и не писал, а писал используя HQL, задавая в качестве запрашиваемых полей и полей после where сами объекты из сущностей, и вот тогда у меня тянулись запросы по цепочке приводя к жутким тормозам... Давно это было, надо бы реализовать и посмотреть как будет вытаскиваться.
Еще дополнительную нагрузку создают всяческие вычисления при выводе данных в таблицу Vaadin типа: "покрасить часть текста в поле в красный, если от даты создания заявки до желаемой даты, когда она должна быть закрыта, прошло больше чем треть времени на текущий момент" :)) и прочее.

Ладно, пока отложу этот вопрос, сегодня доберусь до этих классов и попробую что-то изобразить :)

"Не вижу объяснения в чем проблема с тем чтобы сделать Foreign Key в таблица_2 со ссылкой на Primary Key из таблица_1. "
По этому поводу: таблица User она не растет в ходе закрепления за заявками определенных пользователей, список пользователей пополняется из другого интерфейса. По сути это пользователи системы, со своими логинами и паролями для входа. И так не получится прицепить нескольких пользователей к той или иной заявке.

BlazkowiczВаш подход №5 иногда используют для оптимизации выборки. Но, действительно ли такая оптимизация нужна в вашем случае, это вопрос к вам.
А есть еще какие-нибудь подобные фичи? :)

BlazkowiczNixic,
И эта. Почему вопрос в Java а не в форумах по БД?
Потому что может быть кто-то начал что-то говорить про Hibernate, я там, конечно настройки какие-то делал, но.. мало ли что всплыло бы о нем в процессе.