I have two entities on the system - a Company and a User. There are many more users than Companies but some users will have special privileges to modify the Company. Occasionally multiple users will be able to modify the same Company. I don't see a situation where a user will be able to modify more than one Company at a time, but I don't want to rule out that possibility.
For the database I think it is enough to have a table for company, user, and then a relationship table company_user.
What I'm unsure about is the design of the objects. My implementation will be using Java Hibernate to persist the objects to the database
Right now I'm not 100% sure how this will be handled from the perspective of the UI. For example is the Company added to the User when the user profile is edited, or is the user added to the company when the company profile is edited.
My thinking is that the schools will be associated with the User during the user editing process. But for me it makes more sense to have a collection of users within the Company object, which means when editing a user, I'd also have to save the Company object during the same process, which seems more complicated.
public class Company
private Set<User> users;
I gather this is a fairly common relationship in systems, is there any standard or recommended design? Any thoughts on how I could design this?