Вообще советуют по какому-нибудь бизнес-ключу.
В твоем случае, наверное, uniqueConstraint достаточно. Но это, конечно, если оно у тебя всегда заполнено

MisterCleric, понял, спасибо. На счет сущностей, которые связывают другие, всё же способ не работает:

Создаю запись:
id, device_id, app_id, deleted
(1; 5; 9; false)
Удаляю
(1; 5; 9; true)
Создаю опять точно такую же - 
(2; 5; 9; false)

  

Это сообщение отредактировал(а) Samotnik - 4.5.2011, 16:53

Не понял. Почему "Создаю такую же"?
Ведь это же новая запись: должен быть id новый.
Что у тебя за бардак такой?

MisterCleric, да, извини не дописал, уже исправил, id конечно же новый. Но при чем он тут ? У меня уникальность стоит по полям device_id + app_id именно по этому я не могу создать нового subscriber если уже существует такой же удалённый.

Это сообщение отредактировал(а) Samotnik - 4.5.2011, 16:59

почему бардак 
Вот представь, очень простой пример. Тебе дали задание разработать сущность "Пользователь" с двумя полями Имя, Фамилия. При условии, что нельзя создать двух одинаковых записей с одной именем + фамилией(например нельзя создать Дмитрий Петров дважды   )
Плюс предусмотреть сохранение удалённых пользователей, т.е. не удалять их физически из БД, а каким-либо образом помечать что они удалены и не мешали созданию новых полей (и их удаление) Т.е. БД должна себя вести, как будто этих записей нету в таблице. 
Это я релизовал с помощью флага deleted, путем выставления его в null при удалении записи. С MySQL всё превосходно работало, а вот с Oracle нет.    

Тогда добавь к этой уникальности еще и ID.
Или вообще убери эту уникальность на внешние ключи.
Не понимаю ее смысла.
У тебя что по логике нельзя создать несколько Subscriber на один и тот же Device в одном и том же App?
Да и вообще самый идеальный вариант - провести нормализацию: удаленные записи переносить в архивные таблицы.

не вариант, тогда можно будет создавать Дмитрий Петров сколько угодно раз.

смысл в том, чтобы запретить создавать более одной записи Дмитрий Петров

а это как ?  Можно ссылку или пример ?

нет, нельзя, а какой смысл создавать их несколько ?
Зачем столько записей ? Подписчик должен быть один.
id, device_id, app_id, deleted
(1; 5; 9)
(2; 5; 9)
(3; 5; 9)
(4; 5; 9)
(5; 5; 9)
(6; 5; 9)
....


Это сообщение отредактировал(а) Samotnik - 4.5.2011, 17:57

Не знаю таких ссылок, но на пальцах это так:
1. Копия оригинальной таблицы с префиксом ARC
2. Убираем констрейнты, окромя PK
3. Вызываем обычное удаление
4. В БД на удаление должен быть триггер на каждую таблицу
5. Он должен просто взять удаляемую запись и проинсертить в соответствующую архивную таблицу.
6. Потом ты сможешь эти записи доставать через named-query, а результат повесить на твою основную сущность.

Польза: разделяем данные по логике, повышается производительность на основной таблице.
Минусы: много работы на БД, написание named-query на удаленные записи.

Нужно здесь хорошенько подумать, стоит ли все данные оставлять: может будет нормальным, если какие-то связи все-таки будут удаляться навсегда?

триггер - это ведь sql код. т.е. вручную нужно прописывать, а через хибер можно как-нибудь написать триггер ? 

Если кому интересно, то проблема решилась как всегда - очень просто. 
Поле deleted - сделать типом long по дефолту = -1L, при удалении сетить в это поле тот id, который удаляется  

Добавлено через 6 минут и 7 секунд

так может тогда лучше по id ? 

Привет. Решение красивое.
Сам додумался? 
Век живи - век учись...

По поводу equals & hashCode. 
У меня вот такой вот класс для всех сущностей:


Я, кажись, его тут уже на форуме выкладывал.
Он хорошо работает в рамках логики, которую пишу я. Но для самого Hibernate оно не годиться, так как тот у себя в коде использует класс org.hibernate.util.IdentityMap, который для hashCode вызывает System.identityHashCode, а для equals еще хуже - идет сравнение ссылок.

спс