既屬於第三，獨立的表

關聯兩個表我有三個表：既屬於第三，獨立的表

Topics  Jobs   Requests 
-----   ----   -------- 
title   description request 
description worker_id  user_id 
       topic_id  worker_id 
          topic_id

工人創造的每一個題目的工作。用戶然後可以請求工作人員完成這項工作。

我現在的聯想：

class Topic < AR::Base 
    has_many :jobs 
    has_many :worker, through: :jobs 
end 

class Job < AR::Base 
    belongs_to :topic 
    belongs_to :worker 
    has_many :requests 
end 

class Request < AR::Base 
    belongs_to :user 
    belongs_to :worker 
    belongs_to :topic 
    has_one: :job, through: :topic #This doesn't work, lol. 
end

問題：

我不知道一個請求是否應該屬於一個主題，或作業。

我需要：

訪問請求的主題信息往往比作業信息，但仍然有可用的作業信息。
根據主題和工作人員創建請求，而不是工作。（這很重要。）
列出給定主題的所有請求。
預載請求的主題和作業信息。（同樣重要）

我很猶豫要直接關聯請求和作業，因爲作業包含一些不應該可用於所有請求的信息。有了這種關聯，任何請求都可以訪問這些信息，但也許這不是什麼大問題。

此外，因爲我需要這樣一個緊密關聯的請求和主題，看起來更符合該協會，但隨後我失去了輕鬆的工作訪問。（有了上述關聯，我必須使用自定義方法：Job.find_by(topic_id: self.topic_id, worker_id: self.worker_id)，它不允許預加載或多個請求。）

什麼是最好的方式去這裏？

（讓我知道，如果有更好的標題。）

來源

2014-06-05 znk004

因爲話題總是屬於工作，請求應屬於工作，只有工作。您始終可以將關聯遍歷到主題。這在邏輯上是合理的，因爲用戶請求工作人員完成工作。該主題只是關於該工作的其他信息。如果用戶請求了一個主題，您如何知道他們想完成什麼工作？

在附加說明中，由於工作人員已附加到作業（沒有工人做過他們沒有創建的工作），因此該worker_id應該只在Job模型上，而不是在Request模型上。

切換你的表到這一點，你應該是好：

Topics  Jobs   Requests 
-----   ----   -------- 
title   description request 
description worker_id  user_id 
       topic_id  job_id

來源

2014-06-06 03:02:38 steel

是的，這是事實。用戶請求作業而不是主題，所以我想這就是我的答案。從技術上講，我仍然可以通過topic_id和worker_id找到這份工作 - 它不會是一個適當的關聯。如果我從請求中刪除worker_id，如何找到工人的所有請求？通過工作？謝謝您的幫助。 – znk004

關於通過topic_id找到工作的確如此，我錯過了這一點。爲了得到所有對工人的請求會更棘手，但是通過has_many：through關聯最有效。一名工人通過工作有很多要求。這樣你可以引用Worker。例如，first.requests.load獲取所有第一個工作人員的請求。 – steel

這是有道理的。如果我要通過主題/工作人員id找到工作要求，那麼該協會如何工作？只是想確保我理解這兩種選擇。欣賞它。 – znk004

既屬於第三，獨立的表

回答

相關問題