Hi I have a user model which I used as authlogic. What I need to implement is I have to add staff also to the system. And I designed tables like
users
Let say
you are having staff, directors and managers as part of your system, and their details will be in users table so let say we can build inheritance based relationship like below:
Class User < ActiveRecord::Base end
Class Staff < User end
Class Director < User end
Class Manager < User end
users table: id type name email phone city state etc
Now just you can create staff, directors as follows
staff = Staff.create(:name=>"Tom Mac", :email=>"tom.mac@xyz.com")
So it will create one record in users table and mark the column type with "Staff". Hope it will solve your issue.
Regards. T.Veeraa
Hi Thanks for your reply. This I have already thought of. But one thing I can't understand is why everything is stored in a single table say users here? Can we store each items for say staff,director etc to there own tables? Or Am I wrong?
Tom
why everything is stored in a single table
That's called Single Table Inheritance (STI)
Can we store each items for say staff,director etc to there own tables? Or Am I wrong?
You're not wrong; you can do it with different tables if you want.
Data modelling is done however is best for you. Sometimes you might start with STI, refactor to associations, and then refactor back to STI as your project requirements evolve. Problems may occur when, for instance, your Managers also need to have elements of the properties of Staff - you can't inherit from two base-classes, so you have to start looking at mixing-in modules instead, or of some other method of structuring your data to make it make sense. Also, what happens if you have someone who's a staff member of two offices (if that's possible for your organisation)? Can they have different roles in the different places? etc...
Personally, I tend to keep "users" as a table for authentication-related info, and in my "people" table (I'd tend to avoid STI for people) I keep personal info, link to a user record, and assign a "role" which is used for handling permissions. I'd rather have lots of associations for data, because that's more flexible than one wide flat table (the likes of which STI generally leads to...)
Michael Pavling wrote:
Personally, I tend to keep "users" as a table for authentication-related info, and in my "people" table (I'd tend to avoid STI for people) I keep personal info, link to a user record, and assign a "role" which is used for handling permissions. I'd rather have lots of associations for data, because that's more flexible than one wide flat table (the likes of which STI generally leads to...)
+! for Michael's view.
User, Manager, Staff, Guest, whatever - they're all users of your system. The core definition of a user, and all those attributes can go into a base Users table.
If there are unique attributes for some other 'refinements' of User, I tend to push those attributes out to a related table for the type, allowing a single User entity to be more than one flavor of user. The Guest, being a generic User, doesn't have any relationships.
Just one of many possible solutions, but this type of User modeling has survived many projects.
My question is is this the right approach? And if yes what
would be the relation from users to staffs? I think we can say
staff belongs_to user
But what is the reverse?
user has_one staff
Cheers,
Andy
Hi Lots of thanks for all your reply. What I am finally doing is following. (Is it you people suggested?). I have still problem in creating the view for adding a staff. Please correct me if what I am doing is wrong way.
users
