Sviluppo database MySQL: domini di valori

[m0rdr3d]

Salve a tutti, chiedo un aiuto a tutti gli sviluppatori che conoscono MySQL e che abitano questo forum.

Mi trovo a dover sviluppare un database, per l'appunto in MySQL.
In questo database, come in molti database, sono contenuti dei dati che fanno riferimento ad un dominio di elementi ristretto e solitamente selezionabili tramite una combobox dall'interfaccia.

Ad esempio, se ho un record della classe 'chiamata', al suo interno vi saranno i campi dati 'causa' ed 'esito', da selezionare da un insieme prestabilito (ad esempio causa = { richiesta informazioni | reclami | assistenza tecnica | ecc. }).
Non posso però utilizzare gli ENUM, perchè è necessario che questo insieme sia aggiornabile nel tempo (ad esempio un giorno voglio aggiungere la causa 'auguri di natale').

La soluzione banale sarebbe quella di creare una tabella per ogni 'dominio' e fare riferimento ad essa, ma si verrebbero a creare molte tabelle, che renderebbero la soluzione un po' troppo 'sporca'.
So che per casi simili esistono per l'appunto i 'domini', ma a quanto ho capito MySQL ancora non li implementa.

Chi ne sa più di me potrebbe consigliarmi la soluzione (o consigli) al mio problema?

Spero sia chiaro, intanto grazie mille!

[aschenaz]

Io, molto semplicemente, creerei due altre tabelle "cause" ed "esiti"
e relazionerei a quelle in un rapporto "uno a molti".

[m0rdr3d]

Yes, è quello che farei anch'io, ma in questo modo si verrebbero a creare molte tabelle di una sola colonna, per cui mi chiedevo se ci fossero soluzioni alternative. Altrimenti procedo in questo modo.
Intanto grazie.

[teox99]

"purtroppo" e lo dico tra virgolette, la soluzione a detta degli esperti di SQL e'
(logicamente!) quella classica cioe' creare delle tabelle come suddetto, io a volte cerco di far fare questo lavoro con i file (usando php) filtrando i dati del campo (es. causa) molto piu' semplici e veloci da editare, potrebbe essere una soluzione se non vuoi "sporcare" il DB.

DB: causa -> 001

file contenente i codici:
001 = richiesta informazioni
002 = reclami
003 = assistenza

o includendo i lfile direttamente con gli array
causa[001] = richiesta informazioni
causa[002] = reclami
...

ecc... in questo caso basta aggoirnare il file con i codici filtri.

[aschenaz]

Ma così non faresti altro che dirottare una tabella su codice esterno,
con l'inconveniente (che IMHO non è trascurabile quando i dati diventino
tanti) di dover tener sempre traccia dei codici...

Mi chiedo se ne valga la pena...

[sir_alex]

L'ingegnere del software vi dice: tabelle esterne!
Nella progettazione di un database non è assolutamente un male avere tante tabelle anche di una sola colonna (in realtà saranno due le colonne, di cui una un ID unico per ogni valore, eviterei di fare una uno-a-molti con come chiave un varchar...), anzi è quella la soluzione da adottare.

[teox99]

sono daccordo con sir_alex la soluzione si trova nelle tabelle.
L'uso del codice che ho descritto prima e' un alternativa all'uso di mysql non la soluzione.

[m0rdr3d]

L'ingegnere del software vi dice: tabelle esterne!
Nella progettazione di un database non è assolutamente un male avere tante tabelle anche di una sola colonna (in realtà saranno due le colonne, di cui una un ID unico per ogni valore, eviterei di fare una uno-a-molti con come chiave un varchar...), anzi è quella la soluzione da adottare.

E vedi che avevo ragione io
Il dilemma era nato da una disputa con un ingegnere informatico con cui sto collaborando (io sono informatico _non_ ingegnere) secondo il quale avere tabelle di una colonna (o due contando l'id) e "una grave violazione delle regole relazioniali".
A me la cosa puzzava un po'...

Senza offesa per gli ingegneri, ovviamente

[aschenaz]

E, in ogni caso, IMHO è sempre meglio avere più tabelle "piene"
piuttosto che una sola con colonne semi-vuote, anche nel caso
di un rapporto uno ad uno.
Mi spiego meglio: se avessi una tabella "utenti" con nome, cognome,
telefono, etc., ma solo una parte di loro fosse disposta a fornire,
ad esempio, il numero di cellulare, allora io mi guarderei dall'inserire
una colonna "cellulare"; creerei, piuttosto, una nuova tabella, relazionata
per mezzo dell'"ID" della tabella "utenti"...