我應該在Grails中使用複合主鍵嗎？

的Grails docs鼓勵使用複合主鍵，但在this video（26:00 - 29:00）@BurtBeckwith使用複合主鍵，因爲他談到加入表，而不是使用收藏領域類的映射的性能優勢。這就提出了幾個問題：我應該在Grails中使用複合主鍵嗎？

爲什麼Grails的文檔不鼓勵使用複合主鍵的？
爲什麼Burt甚至使用複合鍵？我嘗試沒有一個，一切似乎都很好。我也沒有覆蓋hashcode或equals。
Burt在製作視頻時使用了Grails 1.3，他對於收藏的表現擔心是否仍然有效？我可以通過打開SQL日誌來自己測試，但我還沒有完成。

來源

2013-07-29 ubiquibacon

休眠更喜歡簡單的主鍵，即使有一個自然的唯一的密鑰（例如，在用戶表中的用戶名），因爲自動遞增的長值作爲外鍵使用更簡單。它當然支持其他方法，GORM也是如此。

我在UserRole表中使用組合PK的原因是保持它與您在GORM中使用多對多時隱式創建的連接表相同。我提出的方法與數據庫相同，但是性能更高，並且您還可以更多地控制定製連接表。但可以隨意將複合PK更改爲簡單的兩個外鍵（理想情況下具有唯一索引）並添加常規單列主鍵。只要您不打算將其用作GORM多對多連接表，這沒什麼。

來源

2013-07-29 21:04:27

是否將UserRole表與隱式創建的連接表保持一致？如果你沒有在連接表上使用複合PK，那麼該表中的每個條目都會有'id'和'version'。我不認爲這是一個巨大的退步，所以我很難理解爲什麼我們會付出額外的努力來創建一個組合鍵。比較兩種方法生成的SQL時，我也感到困惑（將連接表映射爲組合鍵或將連接表映射爲沒有組合鍵）。複合PK方法的SQL似乎更復雜。我可以發佈它，如果你想。 – ubiquibacon

這不是很重要，但工作已完成，現在封裝在生成域類的腳本中。但重要的是不要太擔心默認實現 - 插件和Spring Security不關心用戶和角色數據來自哪裏，只是在某些時候它的格式正確。隨意使用任何你想要的方法，使用自定義的'UserDetailsService'等。 –

我想我可以回答這些問題，但有人糾正我，如果我錯了。

複合鍵不僅僅是Grails的阻礙。作爲一個整體來說，表面設計通常是不鼓勵的。這樣做的最大缺點是與其他表格的關係更加複雜。對於Grails而言，它確實沒有那麼多，而是一般的數據庫設計。
我的猜測是因爲沒有引用UserRole表，它並沒有傷害。他可以使用主鍵，然後在用戶和角色之間創建一個唯一的鍵，但由於沒有其他域引用UserRole，爲什麼添加不必要的字段。如果您不覆蓋hashCode或equals，則無法比較域。
是的，在Grails 2中適用相同的規則，但Grails現在支持Bags。這將提供他在該演講中概述的相同好處，而不會損失當前Grails語法的Groovyness。這不是默認，所以你必須指定。

代碼來設置的集合爲一個包：

Collection books 

    static hasMany = [books: Book]

來源

2013-07-29 20:45:04

包包似乎是一個不錯的主意，但一般情況下它們會變得更糟糕，請參閱http://burtbeckwith.com/blog/?p=1029 –

哇 - 我自己從來沒有使用過包包，但我認爲它們固定了所有包包根據用戶指南中的描述，這是無意義的。 –

我應該在Grails中使用複合主鍵嗎？

回答

相關問題