Hi all, I’m working in a Rails projects and I need to have 2 one to many relationships to the same datatables:
I explain myself:
I have a model Worker and I have a model Job. A Job is made by one Worker and is checked by other. So, I have these fields in the Job class: job_worker and job_checker. In my Job model I added the belongs_to :Worker and in my Worker model I added has_many :job.
This is OK, or I’ve to do something more?
Nope.
class Worker < AR has_one :job end
Nope.
class Worker < AR has_one :job end
class Job < AR belongs_to :worker end
worker_id in this table
–
You received this message because you are subscribed to the Google Groups “Ruby on Rails: Talk” group.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Hi, in tour relationship below, you simply need has_one or belongs_to but not both. It really depends where you would like the foreign key.
For example, if you use has_one, then the foreign key, job_id, will be in the workers table. If you use the belongs_to, the foreign key, worker_id, should be in jobs table.
Last but not least, I would recommend reading the guides.rubyonrails.com for further information. Also, they are a great resource for learning RoR.
Good luck,
-Conrad
Conrad Taylor wrote in post #978329:
Hi, in tour relationship below, you simply need has_one or belongs_to but not both. It really depends where you would like the foreign key.
I think you may have misread the original question. The OP seems to be asking how to relate one job to two different workers. For this he would need two separate foreign keys in his Job model:
Job < AR belongs_to :creator (an instance of a worker) belongs_to :checker (a different worker) end
Here's one way that could be accomplished:
The jobs table
Robert Walker wrote in post #978348:
Here's one way that could be accomplished:
The jobs table +----+------------+------------+-----+ > id | creator_id | checker_id | ... | > 1 | 3 | 7 | ... | > 2 | 1 | 4 | ... | +----+------------+------------+-----+
Also note that this technique does not conform to the First Normal Form (1NF) of database design. An alternative normalized approach would involve associating Job and Worker though a many-to-many association and tagging the worker with a role in the join table.
the job_workers join table
Robert Walker wrote in post #978350:
Robert Walker wrote in post #978348:
Here's one way that could be accomplished:
The jobs table +----+------------+------------+-----+ > id | creator_id | checker_id | ... | > 1 | 3 | 7 | ... | > 2 | 1 | 4 | ... | +----+------------+------------+-----+
Also note that this technique does not conform to the First Normal Form (1NF) of database design.
How do you figure that? It looks well normalized to me. creator_id and checker_id aren't really a repeating group.
An alternative normalized approach would involve associating Job and Worker though a many-to-many association and tagging the worker with a role in the join table.
the job_workers join table +----+--------+-----------+-------------+ > id | job_id | worker_id | role | > 1 | 1 | 3 | creator | > 2 | 1 | 7 | checker | > 3 | 2 | 1 | creator | > 4 | 2 | 4 | checker | +----+--------+-----------+-------------+
This is actually less normalized in the sense that you're repeating the
role name. But that's a quibble. 
However, whether or not it's more normalized, I do agree that the latter approach is the more flexible.
Job < AR has_many :job_workers has_many :workers, :through => :job_workers end
JobWorker < AR belongs_to :job belongs_to :worker end
Don't call it JobWorker! Join models should have descriptive names. How about Assignment?
Worker < AR has_many :job_workers has_many :jobs, :through => :job_workers end
job_1 = Job.find(1) job_2 = Job.find(2)
puts job_1.job_workers.each { |jw| puts "#{jw.worker_id } :#{jw.worker_role}" } => 3 : creator => 7 : checker
puts job_2.job_workers.each { |jw| puts "#{jw.worker_id} : #{jw.worker_role}" } => 1 : creator => 4 : checker
Best,
Thanks guys, you helped me a lot!
Regards,
Marnen Laibow-Koser wrote in post #978380:
Robert Walker wrote in post #978350:
Robert Walker wrote in post #978348:
Here's one way that could be accomplished:
The jobs table +----+------------+------------+-----+ > id | creator_id | checker_id | ... | > 1 | 3 | 7 | ... | > 2 | 1 | 4 | ... | +----+------------+------------+-----+
Also note that this technique does not conform to the First Normal Form (1NF) of database design.
How do you figure that? It looks well normalized to me. creator_id and checker_id aren't really a repeating group.
In a sense it is a repeating group. Consider that adding a third type/role of worker would require adding a third column. However, I'm not necessarily saying that it's a bad thing. Sometimes a less normalized design can be the better design.
An alternative normalized approach would involve associating Job and Worker though a many-to-many association and tagging the worker with a role in the join table.
the job_workers join table +----+--------+-----------+-------------+ > id | job_id | worker_id | role | > 1 | 1 | 3 | creator | > 2 | 1 | 7 | checker | > 3 | 2 | 1 | creator | > 4 | 2 | 4 | checker | +----+--------+-----------+-------------+
This is actually less normalized in the sense that you're repeating the role name. But that's a quibble.
Actually the above table could be considered to be more normalized because it does comply with 1NF. However, it does not comply with the Second Normal Form (2NF). So that's the quibble. If denormalization is considered, then it may be argued that it's better to denormalize from 2NF to 1NF rather than denormalize at the 1NF level.
It is, however, more important to consider what design best fills the needs of the application under a given scenario, rather than blindly following rules of normalization.
However, whether or not it's more normalized, I do agree that the latter approach is the more flexible.
Job < AR has_many :job_workers has_many :workers, :through => :job_workers end
JobWorker < AR belongs_to :job belongs_to :worker end
Don't call it JobWorker! Join models should have descriptive names. How about Assignment?
I absolutely agree with you on this point.