andreykaTЯ того же мнения с Вами (двумя), господа. Но вот говорю ж. меня убеждали в обратном. Я конечно же не сломился, НО, в душе вот думаю а может я действительно неправ.

У меня коллега есть дб-эксперт. он на меня как на идиота посмотрел и извлек: ну да, можно. но зачем? в ряде случаев джойны это только усложняет. (А я вообще в хибере живу - там джойнов нет по-сути, а с критериями ситуация иная, да и вообще это ооп).

Тут вопрос не в хибере, а в дизайне БД. Я для одного проекта решил сделать базу очень каноничной и начитался всякого. Так вот множество ресурсов в один голос рекомендовали комбинированые FK/PK ключи. Соответственно когда ассоциаций несколько PK легко становится композитным. У меня, кажется, до трех в одной таблице дошло. Деталей не помню. Это вам в соседний форум по проектированию БД. Там объяснят лучше.

Но после реализации DAL пришел к выводу, что для Hibernate таки было бы проще добавить синтетический PK во все колонки, а FK оставить только констрейнтом.

Судя по всему, ваши интервьюверы исходили из того что БД первична и спроектировали её именно так. Поэтому им так остро нужны композитные ключи в ORM. И это возникает совершенно флеймовый вопрос. Правильнее ли проектировать сущности из БД путём заковыристого маппинга, или БД из сущностей, упрощая работу с ORM?

andreykaT,

Кажется FK в виде PK нужен для реализации ассоциации один к одному. И вот когда у вас таким образом связано несколько таблиц, и возникает надобность в композитном ключе.

andreykaTдля меня орм первичен.
Ну, вот я бы над этим хорошо подумал. Потому что в каждой системе данные в БД, их целостность и сохранность это самое важное. А какой-то там ORM для CRUD это уже штука вторичная. И приносить дизайн БД в жертву ORM-у, вроде как, не правильно.

Leonid Kudryavtsevмне кажется само по себе ассоциация 1:1 достаточно редкий зверь.

Сейчас посмотрел исходник, это у меня для @ManyToOne такая ересь была. Интересно почему. Столько лет прошло, что уже и не помню.
Один к одному, действительно, исчезающе редкая фигня.


Leonid KudryavtsevВообще, флейм восходит к спору "нужен ли суррогатный PK" или "нужно использовать реальные данные в виде PK, суррогатный ключ зло". Поскольку AFAIK так далеко не заходят и суррогатные PK все же используют ))), то в целом, без комбинированных ключей вполне можно прожить. IMHO

Не-не-не. Суррогатные ключи нужны. Это не обсуждается. Натуральные ключи в качестве PK это куча головной боли.
Давайте на примере из моего старого проекта.

Есть классический "многие ко многим" для сущностей User и Meeting. Но, как это всегда бывает, связь многие ко многим требует аттрибутов, поэтому таблица связи называется Participation и является отдельной сущностью. Внимание вопрос. Чем новый бесполезный генерируемый первичный ключ Participation.id лучше чем композитный первичный ключ fk_user+fk_meeting?
Натуральными ключами тут не пахнет.

andreykaTда, но мы же сущностями думаем (при условии что мы ими думаем). а там крути не крути.. будет три сущности и вантумени к партикипейшн. сущность ты так же скорее всего с пк разрисуешь для хибера. (речь ведь о хибере?)
Не вижу в чем проблема. Могу и так сущность нарисовать.

andreykaTBlazkowicz,

хм. тоже вариант. а эту ембедабл можно притянуть к понятию скуля как "комбинированный ключ" или "вообще без ключа"?
Это и есть композитный ключ.

Локшин МаркЕсть старая, но достаточно хорошая статья по этому вопросу.
Ещё один. Натуральные ключи тут вообще не при чем. Проблема не в них. Вопрос не в них. Зачем вы их приплетаете - не понятно.

Локшин МаркЕсли комбинированный ключ везде , то вопрос тоже касается и применения натуральных ключей, и вопрос в том числе в них. Это как я себе понимаю исходный вопрос.
Хм. Ну, да. Смотря как интерпретировать "везде". Если в каждой таблице, то это ховайся. А если в каждом проекте, то у меня в практике почти так и есть.