Salve avrei la necessità di generalizzare delle tabelle esterne, cioè chiamarle con nomi che terminano con numerazione (es. tabella1; tabella2; etc…) e avere dentro la tabella principale le relative chiavi (chiave1, chiave2, etc…)
dunque avrei
una tabellaPrincipale: id; fk1; fk2; fk3; fk4
4 tabelle (collegate N:1 a tabellaPrincipale) che si chiameranno tabella1; tabella2; tabella3, tabella4
tutto ciò per far decidere all’utente finale il nome e l’ordine di questi 4 modelli.
Si giusto ma in questo caso non conosco nè l’ordine e nè la quantità, l’utente finale può sfruttarle tutte come solo una o due di queste tabelle esterne, e nemmeno quale alias deciderà di applicare a quelle scelte.
In una pagina /site/settings proporrò 4 inputs ordinati (1,2,3,4) , e l’utente gli assegnerà dei nomi (alias), dunque delle relations() dinamiche ? Si potrà mai ?
Si allora, avrei un oggetto (model) X con tante caratteristiche altezza_fk, larghezza_fk, peso_fk etc… con relative tabelle join tbl_altezza, tbl_larghezza, tbl_peso (N:1)
Ora dato che non sò quali e quanti di queste caratteristiche vorrà sfruttare l’utente finale, son disposto a generalizzare, dunque avrò:
Un model principale "X" con le chiavi esterne che si chiameranno 01_fk; 02_fk; 03_fk e e relative tabelle join prenderanno il nome di tbl_01; tbl_02; tbl_03
In questa maniera mi basterà proporre N input all’utente finale, dentro i quali inserirà un ‘alias’ per ogni elemento (es. tbl_01 sarà “Pippo” per l’utente, tbl_02=>“Paperino”) credo che mi servirà una ulteriore tabella per mantenere la relazione tra nome reale del modello (tabella) e l’alias scelto… spero di aver reso la cosa un pò + chiara di prima
A questo punto farei una tabella generica del tipo:
Tabella Caratteristiche:
id_esterno:int;
caratteristica:enum(altezza, larghezza, peso, …) o anche string la lista di scelte è dinamica;
valore:string(?);
In questo modo fai il link tramite la chiave id_esterno e poi nel CDbCriteria puoi aggiungere altre condizioni quando agganci la relation tramite with, del tipo:
Scusami forse ho spiegato male le relazioni, in realtà il model X ha al suo interno tante chiavi esterne quante sono le caratteristiche (tabelle esterne)
Uhm… ma in questa maniera non potrò gestire il crud di ogni ‘caratteristica’ dovrei poter inserire/modificare N altezze… N pesi… e filtrare/cercare anche in base a queste tabelle. Non credo potrò riunire tutti questi dati in una unica table giusto ?
Ad occhio non mi sembra ci siano dei problemi con le crud,
infatti puoi ragionare per caratteristica in questo modo:
se ad esempio $c = ‘peso’, hai una select di questo tipo:
select
cv.*
from caratteristiche_nomi cn
INNER JOIN caratteristiche_valori cv
ON cn.id = cv.id_caratteristica_nome
WHERE cn.nome = $c
quindi tutti i valori di caratteristiche_valori vengono restituiti per caratteristica (in questo caso ‘peso’).
Comunque nel caso più generico ci vogliono 2 tabelle, in modo che se si cambia il nome alla caratteristica (da ‘peso’ a ‘peso totale’ per esempio), non si perdono i collegamenti.
Infatti una cosa a cui stavo riflettendo è che toglierei tutte le chiavi esterne dal model e lascerei il riferimento in caratteristiche_nomi così da avere la flessibilità di aggiungere quante caratteristiche vuoi al model. Così depure il model dalle chiavi esterne e formalizzi:
Tabella caratteristiche_nomi:
id
id_model
nome
Per aggiungere una nuova caratteristica ad un determinato model è sufficiente aggiungere un nuovo record in caratteristiche_nomi.
giusto ?