How to specify relationship between these models

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

name
email
phone etc

staffs

city
state
user_id
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?

Thanks in advance
Tom

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 M.”, :email=>“[email protected]”)

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

On 19 March 2010 11:43, Tom M. [email protected] wrote:

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…)

      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

name
email
phone etc

staffs

city
state
user_id

Now in staff controller
--------------------
def new
@user = User.new
end

staff/new.html.erb

<% form_for @user,:url => staff_index_url, do |u| %>

<%= u.text_field :first_name,:maxlength => 50 %>

<% u.fields_for :staff do |s| %> <%= s.text_field :address_street1,:maxlength => 50 %> <%end%> <%= submit_tag "ok"%> <%end%>

Thanks
Tom

Michael P. 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.