mikele78 ha scritto:
Ci sono installazioni con qualche centinaio di entry nella tabella utente ed altre che possono averne anche 200k.
E allora sistema il codice.
Se è un progetto così grande mi pare il lavoro di un pomeriggio, nel caso peggiore
Ovviamente un'assoziazione tramite una tabella terza sarebbe più pulita ma decisamente più impattante sia per le modifiche che per la necessita di avere sempre una join.
I join non è che siano poi così terribili, in questo caso.
Cambiare il codice mi sembra la scelta più facile, basta che dai sotto di grep per il nome della tabella e inserisci la versione con join
Idea folle, riconvertire questi ruoli in flag expliciti sulla tabella... tipo role1, role2, role3 poi mappati con i ruoli effettivamente presenti e quindi flaggati di conseguenza.
non capisco cosa significhi, ma non è una soluzione.
Il modo più logico sarebbe operare a oggetti, o simil oggetti, o comunque scrivere qualche funzione del tipo
qualiruoli(i_codiceutente) => ritorna l'elenco dei ruoli per un utente
hounruolo(i_codiceutente,i_ruolo) => ritorna vero o falso se ho il ruolo X
con le ausiliarie
aggiungiruolo(i_codiceutente,i_ruolo)
rimuoviruolo(i_codiceutente,i_ruolo)
mascherando il modo effettivo con il quale operano queste funzioni.
inizialmente lasciale uguali (cioè reimplementa il meccanismo che hai ora), a scopo di debug.
decidi poi se i ruoli sono qualcosa di statico, hardcoded nel sorgente, oppure se a sua volta li mantieni in una tabella.
da quanto posso intuire hanno gestioni molto diverse, quindi hardcoded è forse meglio (ovviamente li metterai in un SOLO punto del sorgente)
poi in un "colpo solo", quando l'utilizzo delle funzioni è "rodato", le cambi (aggiungi nuovi ruoli, cambi il db eccetera) et voilà dramma risolto.
tra l'altro questo ti consente facilmente di porre in piedi meccanismi di logging, cosa molto interessante e in generale utile, soprattutto per i ruoli, livelli di accesso eccetera