ID在任何環境中都佔有重要的地位，比如說我們每個人都有個ID，這就是身份證號碼。
當然，也有人有兩個身份證，這些人是異類，在程序中凡是有兩個ID的東西也一樣。
GRAILS中的ID的作用相對於其他系統的ID則更爲巨大。domain默認爲一個domain對象產生一個ID，同時命令行生成的畫面也將ID作爲params的一個重要的參數來傳遞。
如果我們放棄使用ID，我們在GRAILS程序的開發中也不會好受，這就是所有framework帶給我們的缺點。
當你無法改變一個東西的時候，你就得學會適應。
如果你暫時轉不過這個彎，或許我下面談到的內容會讓你的思想得到解脫。
GRAILS是一個整合了多種框架的應用程序框架，作爲一個framework而言，它本身就規定了應用程序開發的具體模式，它在提供各種便利的同時，也將你限制在一定的範圍內。這或許就是framework單詞的frame的意思。
ID作爲GRAILS底層hibernate persist框架的一部分，也不可避免的作爲限制條件將開發手段限制住。
默認的，ID是作爲domain表的主鍵而存在。如果不用ID作主鍵，而用其他的多個字段建立組合主鍵的話，GRAILS命令生成的controller和view就必須作很大的改動纔可用。這樣我們又不得不手寫大量的代碼，這是我們所深惡痛絕的。
從另外一個方面來思考，多個字段的組合主鍵實際上是把多個字段的組合作爲一個唯一的決定條件去決定一個真值表達式，這在關係數據庫的原理當中和ID作爲主鍵並沒有什麼區別。多個字段的組合實際上是一種變相的將業務邏輯存放在數據庫端的解決方案。實際上，如果用constrains將這種商業邏輯以groovy代碼的形式固定下來，要比多個字段組合更爲符合現在的多層的框架。這樣，數據庫的真正功能就和文件一樣，只是作爲一個persist的媒介而存在。在更換persist媒介的情況下，後者顯然要比前者更靈活。估計這也是GRAILS框架設計者的想法。
作爲GRAILS的用戶，個人建議其他用戶沒有必要和GRAILS的默認屬性過不去。從了吧，或許沒有你想象中那麼痛苦。