Ich bin mir nicht sicher, ob ich Ihnen eine funktionierende Code-Datei ohne weitere Informationen geben könnte, aber ich denke, das ist der beste Weg, um fortzufahren.
class User < ActiveRecord::Base
self.table_name = "users"
#Define shared associations/methods
end
class Employee < User
has_and_belongs_to_many :companies
#Employee only associations/methods
end
class Employer < User
has_one :company
#Employer only associations/methods
end
class Company < ActiveRecord::Base
has_and_belongs_to_many :employees
belongs_to :employer
end
Da beide aus dem gleichen User-Modell erben, werden sie einen Tisch teilen. Da beide abgeleiteten Modelle nur has_x verwenden, befindet sich der Fremdschlüssel in der anderen Tabelle, was bedeutet, dass sie ein Tabellenschema ohne eine Tonne von Nullwerten gemeinsam nutzen können.
Wieder bin ich mir nicht sicher, ob das alleine funktioniert, aber ich denke es ist ein guter Anfang. Ein weiterer Vorteil besteht darin, dass Sie durch die Trennung des Codes die Funktionen unabhängig voneinander nach dem Typ der Person ändern können (z. B. können Sie eine generische Protokollfunktion für den Benutzer verwenden, aber für Employee und Employer spezifischer machen, z. B. das Unternehmen oder die Unternehmen einbeziehen) sie sind an gebunden).
Ich erkannte nach der Tatsache, dass es eine andere Möglichkeit, dies zu tun ist. Sie können festlegen, dass der Benutzer eine polymorphe Zuordnung zu Employee oder Employer hat. Dann würden Sie den Benutzerdatensatz prüfen, für welchen Typ er ist, dann ziehen Sie die Assoziation und rufen Sie die Methoden für diesen Datensatz (Employee oder Employer) auf.
Das einzige, was ich ist nicht über diese Lösung mag, dass es drei Tabellen beinhaltet und von dem, was ich Ihnen mit einem Mitarbeiter Modell 1.
Haben Sie tatsächlich erhalten, indem kann gesehen haben? – kurenn
Nein @kurenn. Eigentlich ist Employee kein Modell. Aber das Benutzermodell kann sich wie ein Arbeitgeber oder ein Mitarbeiter verhalten. Übrigens, ich lese dein APIsOnRails-Buch, und ich schulde dir ein Bier. –
Wahrscheinlich wäre ein guter Ansatz, Rollen für Ihren Benutzer und Ihr Unternehmen mit einer has_many-Beziehung hinzuzufügen, wobei die mittlere Tabelle die eigentliche Rolle ist. Macht Sinn? Ich hätte gerne das Bier: P – kurenn