One to many ralationships

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. :slight_smile:

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. :slight_smile:

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.