This has impact on my team's use of jboss tools. If we chose a different name for surrogate key (not 'id') then I'd have a question about changing the generated xhtml and java code.
In short, we want to use a surrogate key, which we believe is the recommendation of Hibernate devlopers. I think Hibernate, Seam and JBoss tools are all using the name 'id' for the surrogate key. 'id' is not meant to be a business (natural) key. The trouble is that 'id' is such a natural name for business level keys. So, we could have a customer id that is known to the user of the webapp; the 'customer id' is NOT the surrogate key.
So, our first try is to build convention that a field named 'sid' would be the surrogate id and 'id' as the natural key. A customer table would have both fields and so we would refer to the business key as the 'customer id'. That seems like a natural fit. The trouble with that is all the code generated by seam which uses 'id' as the surrogate field. I don't think its viable to change the code generators.
Another alternative is to retain 'id' as the name of surrogate key, but use the 'tablename_id' as the business (natural) id. For example, a customer table would have an 'id' and a 'customer_id' field, former is surrogate, latter is natural. I think this could be a bit more confusing than the first option. Developers would get confused if they forgot to put themselves in the business perspective when talking about 'id'.
So, I'm fishing for suggestions from this group on what approach would fit best with the jboss tools and lead to the least confusion.
If you use 'sid' as the surrogate id, how do you work with the seam generated code? Do you generate it and then manually edit? or do you alter the code generator, and how did you do that? As your project progressed, did you suffer any regret?