Quando utilizzo references :foo in una migrazione, la colonna generata è denominata foo_id. C'è davvero qualche differenza tra fare references :foo e semplicemente fare integer :foo_id? Forse qualcosa sta succedendo sotto il cofano per rafforzare la relazione a livello di database?Rails: c'è una differenza tra "reference: foo" e "integer: foo_id"?
Il risultato è lo stesso per il caso specifico; hai ragione. Ma references consente un'opzione :polymorphic => true che creerà automaticamente la colonna foo_type come una stringa nella tabella.
Semanticamente, references è meglio se si sta tentando di rendere le migrazioni migliori rispecchiano le relazioni tra le tabelle nel database.
@ La risposta di Mike spiega bene il significato di references. Tuttavia, spesso è meglio non accoppiare troppo le tue migrazioni alle tue associazioni AR. In particolare, puoi accedere a tutti i tipi di sottaceti quando si tratta di distribuire l'app se esegui le migrazioni prima di aggiornare l'app dal controllo di versione, ad esempio. Non è un grosso problema finché non ti morde :-)
quindi stai suggerendo che i riferimenti possono essere pericolosi? Puoi dare un esempio di che tipo di sottaceto potrebbe farmi entrare? – kdt
In genere ciò può causare problemi se le migrazioni e gli aggiornamenti del codice modello non si trovano nello stesso commit di controllo versione, o se ad esempio si cambia idea sull'associazione in seguito e si ha bisogno di aggiornare una macchina che è troppo indietro rispetto alla curva di il tuo sviluppo. Quindi avresti migration1 che usa 'riferimenti' e quindi determina il nome della chiave esterna dalle associazioni del modello AR. Successivamente decidi di annullare quella migrazione con una nuova e rimuovere anche l'associazione dal tuo codice. Ora, qualsiasi macchina il cui schema è vecchio di 2 generazioni non può eseguire le migrazioni perché l'associazione è andata. – noodl
So che è un po 'contorto. Non dovrei preoccuparmene fino a quando non ti fa veramente male :-) – noodl