On 5/28/07, Lucea [email protected] wrote:
Se tab1_tab2 non contiene altri campi oltre alle due chiavi primarie, ti
bastano due modelli: uno per tab1 e uno per tab2. Poi metti un
has_and_belongs_to_many nei modelli.
Ne contiene altri , per la precisione contiene un’altra chiave e un
campo.
Si deve seguire un’altra procedura?
Probabilmente allora ti conviene definire un modello anche per la
“relazione” intermedia. Per esempio, l’associazione fra “studenti” e
“docenti” puoi modellarla come molti-a-molti, però se vuoi anche
ricordarti
in che anno il docente X ha avuto come studente Y, devi mettere l’anno
nella
tabelal di supporto, che diventa così una entità a sé stante. Cioè passi da
studenti ------ docenti
a
studenti 1 ----- * classi * ----- 1 docenti
con che hai dato un nome alla tabella di supporto, che viene “promossa”
a
entità vera e propria. Hai splittato la relazione molti-a-molti in due
relazioni uno-a-molti. A livello di Ruby allora farai:
class Studente < ActiveRecord::Base
has_many :docenti, :through => :classi
end
class Docente < ActiveRecord::Base
has_many :studenti, :through => :classi
end
class Classe < ActiveRecord::Base
belongs_to :studente
belongs_to :docente
end
A livello di SQL ti tocca aggiungere una chiave primaria alla tabella
“classi”, perché ActiveRecord mal sopporta le chiavi primarie composte da
più di una colonna. Avrai qualcosa tipo
create table classi (
id int primary key auto_increment,
anno_accademico int,
studente_id int,
docente_id int,
unique (studente_id, docente_id)
);
La tua chiave primaria di prima viene sostituita con un vincolo di
unicità,che ha come effetto collaterale di costruire un indice sulla coppia di
colonne, che velocizzerà l’uso delle relazioni uno-a-molti.
M