views:

52

answers:

3

I have a model called Contacts.

Contacts can have different status "bad, positive, wrong..."

These status may need to be changed over time, but across all contacts, they are the same options.

Should I model it this way:

Contacts.rb

belongs_to :status_contact

StatusContacts.rb
has_many :contacts

Then I manually populate the types of status in the table?

I then want to use Ajax to click a button corresponding to a value to update the value for Contacts.

A: 

It looks like you're trying to ensure that the values for your status are always going to restricted to a set of possible answers of your choosing. If that's all you're trying to do, there's no special need for a separate table. You can use the magic of ActiveRecord validations instead here.

First, create a string database column for Contact called :status.

Then you can use a validation to ensure that the values are limited to the ones you want. In Rails 3, you can do it like this:

validate :status, :inclusion => { :in => %w( bad positive wrong ) }

(If you're using Rails 2, use #validates_inclusion_of instead.)

In ActiveRecord, validations check that the object's values are valid before saving; it refuses to persist the object into the database until all validations pass.

Raphomet
-1 if they are changing over time and need to change across all contacts, she's going to need a separate table to store them in.
theIV
I assume she meant that the set of possible values may change over time. Adding a separate table just to restrict the values of a string field is inappropriately heavy-handed for this problem, if I'm reading it correctly.
Raphomet
Perhaps you're right, though it still doesn't get around the fact that if 50 contacts are "positive" and "positive" gets removed or changed, those 50 contacts are still going to be "positive".
theIV
That's true in theory. In my experience, most of the time you just keep on adding more possible values to the list. At any rate, I don't think adding a new table every time you need a string column that can only allow a few possible values is a sustainable practice.
Raphomet
I agree with you. I don't think you should go around adding tables for what boils down to a string column all the time. I think the key difference in terms of this question is if they change over time and you need to change all instances at the same time. Otherwise, you're going to be writing a script that will go and do it for you... which, is totally an option :P
theIV
I agree to agree. :) I think this is really a product design question: by feature launch time, the naming conventions should be stable enough to resist tons of back-change.
Raphomet
the reason it is a table is because I believe the end-user may want to introduce new values or change the specific name of the status....
Angela
A: 

Your naming strikes me as a little weird—ContactStatus sounds a little nicer to me—but I see this as being the general idea to achieve what you want.

theIV
I had ContactStatus, but because I have other Status which I think may need to be separate models (rethinking this) i wanted to be able to look alphabetcially at all Status....
Angela
A: 

No clear answer yet --- I think I need to use the table because it would allow the users to add and modify the types of status used across their application.

Angela