[Ottimizzazione] Usare ENUM conviene?

[Bukowski]

Salve a tutti,
stavo cercando di ottimizzare un pò il mio db.

Se faccio fare un'analisi automatica a mysql con

SELECT * 
FROM annunci_test
PROCEDURE ANALYSE ( ) 

mi consiglia in molti casi l'uso dell'ENUM ...

Ora la domanda che mi sorge è su 2 tipologie di campi che utilizzo:

REGIONI ITALIANE - Attualmente è un varchar 15
mysql mi consiglia di usare un ENUM

ATTIVO - Attualmente è un INT 1 (lo uso per il classico 0 e 1 / attivo non attivo)
anche qui mi consiglia l'uso di ENUM


A livello di performance, quanto è importante usare l'ENUM al posto di un varchar o INT come nei casi sopra?

Ho letto un pò di documentazione qui sul Forum e in giro, ma non si capisce bene se e quanto le performance di un DB possano giovare dall'utilizzo o meno dell'ENUM.

Grazie a tutti

[bubu77]

Premetto che sto parlando solo per istinto, non essendomi mai documentato in merito.

Cmq credo che sia giusto utilizzare in questi casi i campi enum, io li uso spesso.
I miglioramenti dovrebbero derivare dalla lunghezza fissa del campo ma per averne certezza potresti fare delle prove e magari postarle :-)

Ciao

[andr3a]

Originariamente inviato da Bukowski
REGIONI ITALIANE - Attualmente è un varchar 15
mysql mi consiglia di usare un ENUM

le regioni sono un dato in continuo mutamento o solo un vettore statico a memoria prefissata eventualmente comunque aggiornabile in futuro?

Originariamente inviato da Bukowski
ATTIVO - Attualmente è un INT 1 (lo uso per il classico 0 e 1 / attivo non attivo)
anche qui mi consiglia l'uso di ENUM

un booleano (due valori, punto!) pesa più o meno di un INT che richiede potenziale memoria per 2^32 -1 ?

Originariamente inviato da Bukowski
A livello di performance, quanto è importante usare l'ENUM al posto di un varchar o INT come nei casi sopra?

io credo che se ti sei posto la domanda, hai fatto un'analisi automatizzata ed hai aperto un post sul forum hai già bisogno di migliorare le performances ... dico male?

ENUM è un campo a grandezza predefinita dove i nomi sono inutili ai fini della ricerca e la dimensione, un intero unsigned di ridotte dimensioni (ushort o semplicemente un allocazione predefinita ben precisa), è sicuramente inferiore a tipi dinamici ... quindi è escluso non sia preferibile, dove possibile, rispetto il resto.

se fai una struttura ai bassi livelli questa è sempre più performante di una classe dinamica, una struttura predefinita viene riposta in cache e sarà ininfluente per qualunque parte di codice la sfrutti. Se le relazioni devono basarsi su tipi di dato a dimensione variabile (quante verifiche interne ogni query?) piuttosto che su strutture predefinite credo che l'analisi fatta in automatico da MySQL sia solo una conferma a quanto di già detto.

Poi ... magari, alla fine il db sotto è il primo a "fregarsene" di queste cose (vedi SQLite 2) ... quindi non resta che fare un bench su un db normalizzato ad ENUM piuttosto che a VARCHAR (comunque solitamente più lenti) e booleani invece di interi

[Bukowski]

Ciao Andr3a,
ammetto che ho dovuto rileggerlo più volte ma alla fine, ciò che ne evince è ciò che pensavo. Chiaramente un campo "statico" è più performante di un campo dinamico, anche se, mi sembra di aver capito, forse non c'è questa grandissima differenza (anche se su grossi numeri anche una virgola è una grossa differenza.)

Sui manuali di ottimizzazione, siti, forum ecc ecc ... non avendo letto niente sull'ENUM, pensavo appunto, che il guadagno in termini di performance fosse basso.

Stamattina mi dedico a trasformare tutti i campi necessari in ENUM

Grazie a tutti, buona giornata.