Class Person.
Se poi volessi avere Employee, Manager, etc. una cosa da fare sarebbe
derivare queste classi da Person.
L’ereditarieta’ STI, single table inheritation, indica di mettere un
campo type sulla tabella, in questo caso people, in modo da poter
distinguere l’employee dal manager, etc.
Questo va bene se tutte le classi hanno gli stessi attributi.
Se, ad esempio, employee estende person avra’ oltre agli attributi di
person anche degli altri propri.
In questo caso si rende necessario riservare una tabella per employee
ed allora tantovale creare un modello a se stante di Employee senza
necessariamente derivarlo da Person.
Qualcosa mi sfugge?
Io personalmente sono d’accordo, puoi cavartela se c’ un campo di
differenza o due, ma per il resto la STI per le situazioni di effettiva
identit di struttura.
2012/5/4 Mauro [email protected]
Non mi e` chiarissimo…
ma se mettessi due booleani? magari aggiungendo un paio di scope view.
Poi ti gestisci tramite le validazioni i campi obbligatori specifici.
es:
t.string name
t.string code
t.boolean impiegato
t.boolean manager
t.string manager_area
validates :manager_area, :presence => true, :if => :manager?
Ovviamente se le differenze sono molte e` inadatto.
Andrea
On May 4, 2012, at 12:41 PM, Mauro wrote:
ed allora tantovale creare un modello a se stante di Employee senza
necessariamente derivarlo da Person.
Qualcosa mi sfugge?
Forse quello che vuoi e’ una polimorfica piuttosto che sti, in quel caso
hai nella classe base gli attributi comuni e delle tabelle/classi
separate quando l’oggetto e’ differente.
ngw
–
[ 926381, 23200231779, 1299022, 1045307475 ].collect { |a| a.to_s( 36 )
}.join( " " )
Nicholas W. (ngw)
[email protected]
Ciao,
raramente mi sono trovato nei guai con l’STI, ma non nego che qualche
volta successo.
Quindi suggerisco anche io di pensare bene al design prima.
Nel caso che citi mi pare che si tratti di utenti di un sistema (anche
solo potenziali), ed una classica tentazione
per l’uso dell’STI, perch ti consente di avere tutti gli utenti del
sistema in una tabella sola.
In questo caso si rende necessario riservare una tabella per employee
ed allora tantovale creare un modello a se stante di Employee senza
Questo non lo capisco, che vuoi dire?
Nel tuo caso avrai:
class Person
end
class Employee < Person
end
class Manager < Person
end
e la colonna type sar popolata rispettivamente con:
- nil
- Empolyee
- Manager
Se gli attributi e i metodi di employe e manager divergono troppo,
spostali in modelli a parte, con o senza tabelle,
con una relazione has_one o con una banale composition e te la dovresti
cavare bene.
2012/5/4 Fabrizio R. [email protected]:
e la colonna type sar popolata rispettivamente con:
- nil
- Empolyee
- Manager
Se gli attributi e i metodi di employe e manager divergono troppo, spostali in
modelli a parte, con o senza tabelle,
con una relazione has_one o con una banale composition e te la dovresti cavare
bene.
Intendevo questo quando ho scritto che tantovale creare dei modelli a
parte.