[This question][1] seems like it pertains to your question in that it asks something that appears to be implied: should you create a database user for each user accessing the application. And my answer would be an Unreserved NO!

With regards to primary keys and foreign keys, I'd highly recommend you implement both in your database, barring that it should fall upon your Data Access Layer.

One anti-pattern I've seen (and that has been documented by [many others][2]) is the Anemic Model. Where your object mappings to the DB are little more than data transfer objects (setters and getters) that will be operated on by other elements in the application.

Hibernate is a pretty powerful O/RM because it goes beyond just the mapping from the database to objects but it provides true [persistence ignorance][3] allowing your object models to be much more expressive of the business logic.

For example instead of having some operation that takes a Customer and inserts an Order object using the customer id, you'd have a createOrder operation on the customer that adds a new order into your Customer.orders attribute and returns it so you can add line items to it before finally calling save on the context and everything go to the database in one fell swoop.

Read about Domain-Driven Design to see how to make more expressive data layer that does more than just shuttling information back and forth from the database.


  [1]: http://stackoverflow.com/questions/8493711/should-i-need-to-create-mysql-accounts-for-all-the-user-who-register-on-my-websi
  [2]: http://www.martinfowler.com/bliki/AnemicDomainModel.html
  [3]: http://deviq.com/persistence-ignorance/