MySQL: utilizzo di ENUM

[aasmdaa]

Premesso che mi è già stato spiegato che nel caso di valori 0/1, true/false in MySQL è preferibile utilizzare TINYINT(1) mi chiedo un'altra cosa:

se ad esempio ho un campo Priorità che prenderà come valori 'Alta', 'Media' o 'Bassa' è preferibile utilizzare un campo correllato ad un'altra tabella (ad es. tab_stati) con l'id dello stato oppure utilizzare il campo ENUM('Alta', 'Media','Bassa')?

Chiedo perchè io ho sempre utilizzato il primo metodo, ma leggendo su molti siti ci sono pareri discordanti e molti assicurano che utilizzando il campo ENUM in questo caso (con valori fino a 64) sia preferibile per motivi di indicizzazione, velocità semplicità delle tabelle.

Voi quale opinione avete in merito?

Grazie
ciao

[piero.mac]

utilizzare ENUM i motivi li hai gia' elencati tu.

Aggiungerei quello di avere sicuramente nel campo i valori previsti

[aasmdaa]

Ok per cui anche tu sei di questo avviso.
Io l'ho sempre evitato, ma in questo giorni l'ho utilizzato per alcuni campi e devo dire che risulta molto comodo in alcuni casi.

[deleted_29]

consiglio: fai finta che gli enum non esistano.

Usa un normalissimo campo integer.
riduci del 99.99% le difficoltà nel portare verso un altro db che NON ha il supporto enum.

enum? se li conosci, li eviti.

[aasmdaa]

Infatti è ciò che ho fatto fino adesso. Però sembra che effettivamente l'unico motivo per cui non utilizzarlo sia quello della portabilità verso un altro tipo di database.

Se però sei sicuro di non dover fare una migrazione sembra sia una buona soluzione.

[deleted_29]

Originariamente inviato da aasmdaa
Infatti è ciò che ho fatto fino adesso. Però sembra che effettivamente l'unico motivo per cui non utilizzarlo sia quello della portabilità verso un altro tipo di database.

Se però sei sicuro di non dover fare una migrazione sembra sia una buona soluzione.

ahem... ma quali "pregi" avrebbe?
Compattezza? no
Prestazioni? no (* se si eliminano i join e si decodifica in applicazione)
semplicità di utilizzo? no

l'unico "vantaggio" è avere, nei risultati delle query, il codice-decodificato. Normalmente, infatti, gli enum si usano per piccoli insiemi, che si possono de-codificare hardcoded lato applicazione.
alto, basso,medio, non c'è bisogno di usare un'altra tabella e fare un join.

Anzi ti dirò di più: nel caso in cui, a tutti i costi, si voglia avere la "pappa fatta" suggerirei direttamente un campo stringa con dentro
"alto", "basso", "medio".
1000000000000000000000000000000 volte più facilmente gestibile

[aasmdaa]

Ok mi hai ri-convinto. Per me non ci sono problemi a continuare ad utilizzare le tabelle unite da chiavi esterne dato che ho sempre fatto così.

Volevo solo un'opinioni dai più esperti di me sui DB.

Unico dubbio che mi lasci è:

che si possono de-codificare hardcoded lato applicazione.

cosa significa?

[deleted_29]

Originariamente inviato da aasmdaa
Ok mi hai ri-convinto. Per me non ci sono problemi a continuare ad utilizzare le tabelle unite da chiavi esterne dato che ho sempre fatto così.

Volevo solo un'opinioni dai più esperti di me sui DB.

Unico dubbio che mi lasci è:





cosa significa?

Evidentemente non ti ho convinto.

Decodificare lato applicazione significa trasformare il codice del campo nella descrizione, da programma.
Ossia il programma "sa" che se c'è il campo=0 significa "basso"; campo=1 "medio"; campo=2 "alto".

Se non vuoi mettere "intelligenza" nel programma per codificare-decodificare i campi (quindi NIENTE tabelle di appoggio esterno, ultralente), come accennato, metti direttamente i campi decodificati.
Invece di avere ENUM('alto','medio','basso') un CHAR(5) dove ci piazzi "alto", "medio", "basso".

E se già stai cominciando a porti problemi esistenziali di prestazioni blablabla, puoi anche lasciarli stare nel 99.999999% dei casi, giacchè il "costo" di campi "corti" non è poi così maggiore rispetto ad interi

[aasmdaa]

Ottimo tutto chiaro.

Approfitto per chiederti ancora una delucidazione in merito alla frase "(quindi NIENTE tabelle di appoggio esterno, ultralente)": intendi le tabelle di riferimento?

Tabella ANA_NOMI
Nome: pippo
Stato: 1

Tabella ANA_STATI
ID: 1
Stato: 'alto'

Ovvero ANA_STATI in questo caso? Perchè scrivi 'ultralente'?

Questo è il metodo che ho sempre utilizzato io (normalizzazione).

Non è che mi faccia un problema di prestazioni, è solo curiosità.

[deleted_29]

Originariamente inviato da aasmdaa
Ottimo tutto chiaro.

Approfitto per chiederti ancora una delucidazione in merito alla frase "(quindi NIENTE tabelle di appoggio esterno, ultralente)": intendi le tabelle di riferimento?

Tabella ANA_NOMI
Nome: pippo
Stato: 1

Tabella ANA_STATI
ID: 1
Stato: 'alto'

Ovvero ANA_STATI in questo caso? Perchè scrivi 'ultralente'?

Questo è il metodo che ho sempre utilizzato io (normalizzazione).

Non è che mi faccia un problema di prestazioni, è solo curiosità.

normalizzazione significa, per un rdbms, join.
e join significa "ultralento".
il carico di lavoro di un join, anche semplice, è enorme per qualsiasi db, questo al di là della cardinalità delle tabelle, dell'esistenza di indici, selettività delle stesse, pianificatore query etc.

in breve join=ultralento, se puoi evitarlo tanto meglio.
Se gli stati sono pochi (nel tuo esempio), ti basta decodificarli da programma.
Fine dei join-> via gli ultrarallentamenti.

"normalizzare" ha pregi e difetti. spesso più difetti che pregi. occorre conoscere entrambe le facce della medaglia, per scegliere come progettare un db