Per me è come utilizzare valori con hardcoded anziché variabili costanti nel codice dell'applicazione. Ma ci sono opinioni diverse là fuori. Quindi non posso davvero decidere di sicuro.Sta usando mysql ENUM una cattiva soluzione architettonica?
P.S. Per lo scopo di questa domanda assumiamo che le prestazioni non siano un problema.
Dipende da cosa stai cercando di ottenere, davvero. Se la performance, come dici tu, non è un problema, dipende in gran parte dalla tua filosofia e dalla mutevolezza intrinseca dei dati. Se stai utilizzando un ENUM per memorizzare i valori per i giorni della settimana, per facilitare la leggibilità umana e la 'queryability' dei dati, allora è un uso perfettamente valido (e di gran lunga superiore, in alcuni casi, all'uso di numeri o altro rappresentazioni). Se, tuttavia, lo stai usando per memorizzare cose come la categoria in cui si trova un prodotto (per cui l'insieme delle categorie disponibili potrebbe facilmente cambiare), allora è una soluzione molto povera.
Questo dipende molto dalla situazione attuale, ma il punto dei tipi di colonna in primo luogo consiste nel definire con precisione quali valori sono consentiti e quali no. Se, nel tuo dominio problematico, l'attributo che stai considerando di memorizzare come valore ENUM, è corretto nel nel senso che non è possibile avere altri valori, quindi ENUM è un'ottima scelta. Un esempio di questo sarebbe il genere: ENUM('male', 'female') è ottimo, perché la possibilità di un terzo genere da aggiungere sarebbe davvero molto bassa.
Se si memorizzano valori che sono più suscettibili di modifiche, è possibile prendere in considerazione la possibilità di normalizzare il modello dati in una relazione molti-a-uno.
Supponi di dover tradurre questo in un'altra lingua, o supponi che il business imponga invece di accettare "M" e "F". – MattK
@MattK quelli sono problemi di applicazione/interfaccia, non problemi di dati. – molf
Vedo quello che stai dicendo, ma ENUM sta già mixando l'interfaccia con i dati. Se volessimo questi dati puri, usiamo solo 0 e 1, quindi. Se vuoi che il tuo DB abbia qualcosa di più leggibile (come "maschio" e "femmina"), cosa succede se c'è un bisogno futuro di cambiare i dati (come l'internazionalizzazione)? – MattK
Non in alcun modo! Hanno diversi vantaggi rispetto a un campo numerico:
Infatti, utilizzando valori numerici invece di enumerazioni è come mettere costanti nel codice sorgente.
ENUM è ottimo per i dati che si sa rientrano in un set statico.
Se si utilizza Mysql 5+, l'archiviazione is almost always better con un tipo ENUM per i dati in un set statico, come illustrato nel riferimento MySQL ufficiale. Per non parlare del fatto che i dati sono leggibili e che hai un ulteriore livello di validazione.
Se si desidera sapere se l'utilizzo di ENUM sarà un'ottimizzazione, è consigliabile utilizzare PROCEDURE ANALYZE. Questo consiglierà il tipo di dati corretto per le tue colonne.
Lo svantaggio pratico è l'allungabilità. Non è possibile aggiungere un valore all'elenco senza aggiornare l'intera tabella. Non è possibile contrassegnare i valori come storici. L'elenco dei valori è limitato. Sebbene tu possa avere il meglio da entrambi quando sposti la funzione lista sul modello MVC della tua applicazione e lasci che il tipo di colonna sia CHAR. A meno che le prestazioni e l'archiviazione non siano entrambi elementi chiave per l'applicazione, non raccomanderei l'uso dell'enumerazione quando il database viene utilizzato solo dalle applicazioni. – Code4R7