Использование составного ключа в GORM - PullRequest
1 голос
/ 12 января 2011

В разделе 5.5.2.5 документа grails говорится:

GORM поддерживает концепцию составных идентификаторов (идентификаторов, составленных из 2 или более свойств).Мы не рекомендуем такой подход, но он доступен вам, если он вам нужен

Почему это плохая идея?У меня есть следующее определение таблицы:

User (Table)
   Column: userId (Primary Key)

FriendMap
   Composite Key Column: userId (foreign key from User) and friendId

Это плохая идея?

Ответы [ 3 ]

0 голосов
/ 24 января 2011

Я вижу доказательства того, почему это не рекомендуется.Класс friendMap, который имеет составной ключ, также имел «version = false».

В некоторых случаях я получал:

org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1
        at org.hibernate.jdbc.Expectations$BasicExpectation.checkBatched(Expectations.java:85)
        at org.hibernate.jdbc.Expectations$BasicExpectation.verifyOutcome(Expectations.java:70)
        at org.hibernate.jdbc.BatchingBatcher.checkRowCounts(BatchingBatcher.java:90)
        at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:70)
        at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:268)
        at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:266)
        at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:172)
        at org.codehaus.groovy.grails.orm.hibernate.events.PatchedDefaultFlushEventListener.performExecutions(PatchedDefaultFlush
EventListener.java:46)
        at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:50)
        at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1027)
        at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:365)
        at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:137)

Я недавно видел это, когда удалял объект FriendMap,Это также не происходит все время.Я нашел комментарии онлайн, что это может быть проблемой с версией = ложь и составным ключом.Я решил вернуться к одному числовому, увеличивающемуся полю id.С тех пор я не видел никаких проблем.Я не знаю всей проблемы, но я бы не советовал составной ключ с отключенным контролем версий.

0 голосов
/ 13 февраля 2012

Я совершенно не согласен с ребятами из Grails на этот счет. Составные ключи обеспечивают согласованность вашей базы данных и во многих случаях необходимы для правильной нормализации базы данных.

См http://weblogs.sqlteam.com/jeffs/archive/2007/08/23/composite_primary_keys.aspx

Это важная базовая концепция моделирования баз данных, и я удивлен, что она скрыта в граалях.

0 голосов
/ 12 января 2011

Идея объединения таблиц, используемых для сопоставлений «многие ко многим», не так уж плоха. Вот как выглядит ее использование.

Существует ряд аргументов против использования составныхключи вместо использования одного числового, увеличивающегося поля идентификатора.В основном они включают усложнение изменения и рефакторинга вашего домена.

Для классов сопоставления хорошим примером является класс сопоставления Берта между пользователем и ролью для spring-security-основной плагин.

...