I have couple of confusions as regard to having the ID (Primary) key on the UI layer,

1. Is it really a bad idea to have UI layer knowledge of the ID of the a row in a databse ? If yes then why ? What can happen if UI layer ( or JSP) knows about this ID ?
 I was told that it might be a problem with the security. But even if some user knows the ID of a particular row, what can s/he do? No one can do anything in the database unless s/he has the proper authirozation.

2. I used hibernate with spring in the previous project, i had ID of the row as hidden fields on the jsps. I will have these IDs passed in the business layer but when u try to update the row, it gives error indicating i have 1 more object with same id associated with the session as the object coming from UI layer had ID in it. So i had to set the ID to null.

 The problem is that at one time there can be just one object in table and in session with the same id.

 But if i use surrogate keys then i end up firing queries in database to fetch the row(s) which i want to avoid...

whats the best way to deal with such things ? Any ideas?


Thanks in advance and regards
Sandeep

As I understand it, (1) is more of a matter of the possible consequences if you're using a value that's directly used by the user as a key, rather than it being visible. Even then, it's more a matter of protecting yourself from changes if there later comes a requirement to change the column format in some way, etc.

As regard to 1, the primary key is just a number. It gets incremented when a new row is inserted. Why would anyone like to change it ? All the business data is stored in columns against this ID (which is just a number ).
If someone is changing the type of business data, the ID key will not be impacted.