Должен ли я использовать составные первичные ключи в Grails?

Question

Grails docs препятствует использованию составных первичных ключей, но в this video (26:00 - 29:00) @BurtBeckwith использует составные первичные ключи, поскольку он говорит о преимуществах производительности сопоставления таблиц объединений классам домена, а не использования коллекций. Это вызывает несколько вопросов:

1. Почему Grails docs препятствует использованию составных первичных ключей?
2. Почему Берт даже использует сложный ключ? Я пробовал без одного, и все, кажется, работает нормально. Я также не переопределял hashcode или equals.
3. Берт использовал Grails 1.3, когда это видео было сделано, относятся ли его проблемы с производительностью относительно коллекций? Я могу проверить это самостоятельно, включив ведение журнала SQL, но я еще не сделал этого.

Answer 1

Hibernate предпочитает простой первичный ключ, даже если есть естественный уникальный ключ (например, имя пользователя в таблице пользователей), так как Автоинкрементный долго значения проще использовать в качестве внешних ключей. Конечно, он поддерживает другие подходы, а также GORM.

Причина, по которой я использую составную PK в таблице UserRole, заключается в том, чтобы она была такой же, как и неявно созданная таблица соединений, которую вы получаете, когда используете GORM многозначительную. Подход, который я предложил, должен был быть таким же, как и в базе данных, но более производительным, и у вас также есть больший контроль над настройкой таблицы соединений. Но не стесняйтесь менять составную PK на два внешних ключа (в идеале с уникальным индексом) и добавлять обычный первичный ключ с одним столбцом. Это прекрасно, если вы не планируете использовать его в качестве таблицы объединения GORM many-to-many.

Answer 2

Я думаю, что могу ответить на эти вопросы, однако кто-то меня исправит, если я ошибаюсь.

1. Композитные ключи не являются чем-то, что только Грейлс обескураживает. Как правило, это обескураживает дизайн стола в целом. Самым большим недостатком этого является то, что он делает отношения с другими таблицами более сложными. Это действительно не так много связано с Grails, а скорее с дизайном базы данных.

2. Мое предположение заключается в том, что, поскольку ничто не ссылается на таблицу UserRole, это не повредит. Он мог использовать первичный ключ, а затем создал уникальный ключ между пользователем и ролью, но поскольку ни один другой домен не ссылается на UserRole, зачем добавлять ненужное поле. Если вы не переопределите hashCode или equals, вы не сможете сравнить домен.

3. Да, те же правила применяются в Grails 2, однако Grails теперь поддерживает Bags. Это обеспечит те же преимущества, которые он изложил в этом разговоре, не теряя Groovyness текущего синтаксиса Grails. Это не значение по умолчанию, поэтому вам нужно будет указать.

код, чтобы установить коллекцию как сумка:

Collection books 

    static hasMany = [books: Book]