# L'ereditarieta' in rails

**URL:** <https://www.ruby-forum.com/t/lereditarieta-in-rails/219488>\
**Category:** IT\
**Created:** [May 4, 2012, 12:41pm UTC](https://www.ruby-forum.com/t/lereditarieta-in-rails/219488 "2012-05-04T12:41:56Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Gurdipe\_D](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/b77776/32.png) [@Gurdipe\_D](https://www.ruby-forum.com/u/Gurdipe_D)\
**Post date:** [May 4, 2012, 12:41pm UTC](https://www.ruby-forum.com/t/lereditarieta-in-rails/219488/1 "2012-05-04T12:41:56Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![msan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/3ab097/32.png) [@msan](https://www.ruby-forum.com/u/msan)\
**Post date:** [May 4, 2012, 12:53pm UTC](https://www.ruby-forum.com/t/lereditarieta-in-rails/219488/2 "2012-05-04T12:53:42Z")

</div>

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 [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

---

<div class="post-metadata">

**Author:** ![msan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/3ab097/32.png) [@msan](https://www.ruby-forum.com/u/msan)\
**Post date:** [May 4, 2012, 1:26pm UTC](https://www.ruby-forum.com/t/lereditarieta-in-rails/219488/3 "2012-05-04T13:26:21Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![msan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/3ab097/32.png) [@msan](https://www.ruby-forum.com/u/msan)\
**Post date:** [May 4, 2012, 9:45pm UTC](https://www.ruby-forum.com/t/lereditarieta-in-rails/219488/4 "2012-05-04T21:45:50Z")

</div>

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)  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

> **[NoFeed Ltd ~ Nicholas Wieland (ngw)](https://nofeed.org)**
>
> Nicholas Wieland, freelance Ruby and Ruby On Rails developer, DevOps, project and egineering manager. Story, informations, contacts.

---

<div class="post-metadata">

**Author:** ![msan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/3ab097/32.png) [@msan](https://www.ruby-forum.com/u/msan)\
**Post date:** [May 4, 2012, 10:37pm UTC](https://www.ruby-forum.com/t/lereditarieta-in-rails/219488/5 "2012-05-04T22:37:14Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![msan](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/3ab097/32.png) [@msan](https://www.ruby-forum.com/u/msan)\
**Post date:** [May 4, 2012, 10:59pm UTC](https://www.ruby-forum.com/t/lereditarieta-in-rails/219488/6 "2012-05-04T22:59:30Z")

</div>

2012/5/4 Fabrizio R. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

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