你曾經這樣做過嗎？兩個模型類 - 一個數據庫表
我正在寫一個Rails應用程序。我有一種情況，我有一個任務模型（和表），任務有屬性，允許查看它的人員和層次結構（可能在項目或業務下）。
我也有一個AssignmentController，它將一些視圖和功能公開給分配給Task的個人 - AssignmentController使用Task.find來獲取任務，並且與Task是同一個對象 - 它只是由受讓人更新並且只有幾列可供受讓人使用。在這種情況下，我想隱藏一些用戶界面，更改佈局以適應業務，而層次結構對任務的受讓人無關緊要。
我在做的是創建一個Task模型和Assignment模型，它們都指向同一個表格（任務表）。我不明白爲什麼我不應該這樣做。這將允許我減少Assignment模型類並隔離僅由Task使用的方法。據我所知，它也會使代碼更清潔。
我在網上搜索時沒有看到關於這種模式的很多內容。對此有何意見？
感謝您的想法...
如果我理解正確，您想繼承表:) 好主意，不明白爲什麼它不會工作... set_table_name「任務」將做到這一點，或者只是任務模型的子類。 但是，在這兩種情況下，您都會遇到關聯問題，您必須定義belongs_to：task和belongs_to：爲任何has_many關聯分配它，您希望這樣做正確...
編輯： 其實忘了我說的:) http://railscasts.com/episodes/154-polymorphic-association
你應該在Assignee和Tasks之間有一個連接表。如果您的天氣陳述或者您沒有受讓人或任務，您的建議可能會導致您的觀點雜亂無章。如果你發現你在兩者之間使用類似的html塊，你可以簡單地使用partials。
此外，您的提議有些不贊成數據庫正常化。標準化不僅僅是你今天需要的，而且明天你可能需要的。如果您沒有關於受讓人的更多信息而不是用戶名，則可以爲兩個模型（種類）使用相同的表格。但是如果你想知道更多關於Assignees的信息，那麼以後呢？
我同意這很奇怪 - 但在我的情況下，我不需要type列（在STI中），我只想改變一些方法（例如，擁有它的業務）。其他一切都寧靜。它也使用Declarative Auth - 插件使用默認變量名稱和類型（@assignment，Assignment）更好。我有belongs_to，has_one，但那比我需要的多。我爲每項任務創建了作業。總體而言 - 這只是一個方便，保持寧靜的控制器。 感謝您的想法。很高興知道我打破了什麼規則。 – Swards 2010-02-01 21:22:48
我還在研究這個。我只是模型，並嘗試在腳本/控制檯中，它似乎工作正常。如果需要，您甚至可以像這樣訪問「任務」。 has_one：task，：foreign_key =>：id 最終，這可以讓我在每個模型上都有一個「業務」方法，指向不同的業務。 一個預期問題 - 任務上的任何多態項目（如照片）不在任務上，但可以通過任務進行訪問（如有必要）。 – Swards 2010-01-29 05:31:29