2

Grailsのドキュメントでは複合主キーの使用を推奨していませんが、このビデオ(26:00 - 29:00)では、 @BurtBeckwithが複合主キーを使用して、コレクションを使用するのではなく、結合テーブルをドメイン クラスにマッピングすることのパフォーマンス上の利点について話しています。 . これにより、いくつかの疑問が生じます。

  1. Grails のドキュメントが複合主キーの使用を推奨していないのはなぜですか?
  2. Burt が複合キーを使用しているのはなぜですか? なしで試してみましたが、すべてうまくいくようです。hashcodeorもオーバーライドしませんでしたequals。
  3. そのビデオが作成されたとき、バートは Grails 1.3 を使用していましたが、コレクションに関する彼のパフォーマンスの懸念はまだ有効ですか? SQL ロギングを有効にすることでこれを自分でテストできますが、まだ行っていません。
4

2 に答える 2

3

自動インクリメントの長い値は外部キーとして使用する方が簡単なので、Hibernate は単純な主キーを好みます。もちろん、他のアプローチもサポートしており、GORM も同様です。

UserRole テーブルで複合 PK を使用する理由は、GORM で多対多を使用するときに取得する暗黙的に作成された結合テーブルと同じにするためです。私が提案したアプローチは、データベースに関する限り同じであることを意図していましたが、よりパフォーマンスが高く、結合テーブルのカスタマイズをより細かく制御できます。ただし、複合 PK を単純な 2 つの外部キー (理想的には一意のインデックスを持つ) に自由に変更し、通常の単一列の主キーを追加してください。これは、GORM 多対多結合テーブルとして使用する予定がない限り問題ありません。

于 2013-07-29T21:04:27.063 に答える
2

I think I can answer these questions, however someone correct me if I'm wrong.

  1. Composite keys aren't something that just Grails discourages. It's generally discouraged in table design as a whole. The biggest drawback to doing so is that it makes relationships with other tables more complex. It really doesn't have that much to do with Grails, rather database design in general.

  2. My guess here is that because nothing references the UserRole table, it doesn't hurt. He could have used a primary key, then just created a unique key between user and role, but because no other domain references UserRole, why add the unnecessary field. If you don't override hashCode or equals, you won't be able to compare the domain.

  3. Yes, the same rules apply in Grails 2, however Grails now supports Bags. This would provide the same benefits he outlined in that talk, without losing the Groovyness of the current Grails syntax. This is not the default so you would have to specify.

Code to set a collection as a Bag:

   Collection books

   static hasMany = [books: Book]
于 2013-07-29T20:45:04.920 に答える