针对hibernate应用的表设计，最好设计一个非逻辑主键id吗？大家怎么做的

hibernate的应用，一定需要主键的。

 

很多书上或网页都推荐针对hibernate的表设计时，设计一个独立的主键id，跟业务逻辑无关系的。但是我在实际应用中，发现有些业务涉及主外时，使用跟业务逻辑有关的主键很方便。

---

问题补充：谢谢各位，这几天忙去了。 
确实主键和业务脱离，能增加灵活性。 
现在，我总结下，看对不对 
用独立主键： 
优点： 
1. 能和业务逻辑解偶，如后期的业务变化，主键不会变化（这个比较重要，一般程序里getId()被用到的地方很多） 
2. 知道id的情况，访问数据比较快，直接，且方便做成通用处理（各表主键id同名） 
缺点： 
1. 有时访问数据不大方便，应用上经常关心业务数据，在这种情况下，如果要得到记录，需要先得到id，再利用id，得到记录 
2. 业务应用上，业务主键字段用于查询比较多，通常会建立索引，这样主键id也有索引，索引多了，增加了空间，影响更新速度 
3. 如要对数据做主外键（业务上的数据约束），由于表主键只有一个，这时建立不了约束 

----- 
对数据完整性约束要求较高的情况下（如数据比较总重要，不能出错的情况下），用业务逻辑字段做主键。其它情况用独立主键。 
另外，用独立主键时，在hibernate中，可以建立维护主外键关系（这样应该可以吧，相当在应用层约束数据完整性）