views:

51

answers:

2

I want to have a model called Status which will be relatively static after some user-defined set up (and different users may have different values on status).

The status can apply to different Models, such as Contact and Events.

so contact.status set of possible values will be different from event.status

I want to design the app so that status table has different types (contacts and events).

What is the right strategy and format for this?

I am thinking of saying that:

Contacts :has_one Status

and store a status_id in the contacts table. Ditto with Events.

Status table will have the status value, type, and date.

does this make sense? Can you suggest a better approach?

A: 

Firstly, the has_one relationship does not store an id in the current model. It looks for a foreign key in the relative table. In order to store a status_id in Contacts or Events you'd use belongs_to.

Secondly, depending on the type of information you're storing in Status, why does it need to be its own separate table? Why not make a status column in each model you want to use status on? A little more information may be useful here.

nuclearsandwich
Well...it could be. It seemed that I've seen ERD's set up where certain attributes that were pretty standardized tended to be separate tables. Since as I noted above the status values do not change much, it seemed like that would be the sort of thing in its own table, especially since it will be made available as a drop-down or auto-complete as an attribute.
Angela
+2  A: 

There is a guide on this very question. Your situation is slightly different in that it seems as though your Status model really needs to be polymorphic since different things will be 'statusable'.

To answer your question, Contact/Event has_one Status does make sense to me.

theIV
my status model is polymorphic....I edited it above....I'm wondering whether I should make things simple since it seems to be hard to search on it...harder than I thought
Angela