[MySQL] Tipo di dati degli attributi

[Jamie04]

Secondo voi, per campi i cui valori possono assumere solo due stati (ad esempio: confermato/annullato, aperto/chiuso) è più conveniente usare un tipo di dato CHAR (lettera singola, tipo C o A) o un booleano?
Nell'applicazione (web) potrebbe risultare in un semplice flag da mettere in un punto o in un altro. Chiedo cosa potrebbe essere meglio soprattutto per eventuali interrogazioni etc.

Ancora, il tipo DATE viene automaticamente formattato col formato americano, giusto? Non esiste il formato italiano? Nella maschera di inserimento del dato, sempre via web, come mi comporto?
Grazie.

[zacca94]

Secondo voi, per campi i cui valori possono assumere solo due stati (ad esempio: confermato/annullato, aperto/chiuso) è più conveniente usare un tipo di dato CHAR (lettera singola, tipo C o A) o un booleano?

mah in caso confermato/no utilizzi ENUM, char probabilmente è la peggiore fra le scelte... comunque non ci sono convenzioni a riguardo.
Dipende molto dal campo di provenienza, la maggior parte usano TINYINT (0/1).

Nell'applicazione (web) potrebbe risultare in un semplice flag da mettere in un punto o in un altro. Chiedo cosa potrebbe essere meglio soprattutto per eventuali interrogazioni etc.

Per ragioni di logica tinyint è quello che occupa meno spazio.

Per ragioni di teoria dipendentemente dall'hardware io azzarderei (anche se qui qualcuno che sa esattamente come funzionano i RDBMS e come sono programmati potrà eventualmente corregermi) anche a utilizzare un INT da 32 bit o un INT da 64 bit o una INT da 128 dipendentemente dalla architettura hardware in quanto occuperebbe esattamente la dimensione fissa del registro della CPU, quindi anche se occupa più spazio, l'importante è quanti loop effettua per caricare il registro.

In pratica: se ne sbattono tutti perchè non ha senso neppure nel 2017 spendere in test per vedere il tipo di dato più adatto per la tua macchina, quindi per convenzione il tipo di dato è piccolo utilizza TINYINT, quando è medio SMALLINT e così via... Oppure se vuoi usare ENUM per fare 0/1, o CHAR (ma in quel caso non mostrare il codice se vuoi che ti assumano).

Ancora, il tipo DATE viene automaticamente formattato col formato americano, giusto? Non esiste il formato italiano? Nella maschera di inserimento del dato, sempre via web, come mi comporto?

Molti non utilizzano neppure DATE, ma salvano la data in UNIX TIMESTAMP e poi la processano con il linguaggio che utilizzano.
Comunque esiste DATE_FORMAT, per formattarla come vuoi.

[badaze]

Il formato data di mysql non è il formato américano. È il formato ssaa-mm-gg che peraltro è l'unico formato che consente di ordinare le date in maniera corretta.
Imho convertire una data in formato timestamp unix non ha senso visto che gli SQL hanno le funzioni per estrarre anno, mese giorno etc...

[zacca94]

Imho convertire una data in formato timestamp unix non ha senso visto che gli SQL hanno le funzioni per estrarre anno, mese giorno etc...

Boh, io usando solo MySQL non ho questo problema, ma forse il tutto è utilizzato in framework che supportano i vari database utilizzati, ciò dovrebbe permettere la stessa query indipendentemente dal DBRMS scelto dall'utente durante la configurazione.

[badaze]

Da non dimenticare.... il but unix del 2038 !

[zacca94]

Da non dimenticare.... il but unix del 2038 !

L'importante è che non ne soffrano anche le tue calcolatrici

[badaze]

Per fortuna pochissime hanno un orologio e quelle che ne hanno uno non mi sembra abbiano superato quello del 2000.

[Jamie04]

perché CHAR è la peggiore fra le scelte?

[zacca94]

perché CHAR è la peggiore fra le scelte?

Ipotizzo:

1) Non è quella che occupa meno spazio;
2) Non è quella più veloce;
3) Sono sviluppati altri tipi per fare i confronti e le scelte di cui parli (come ENUM);
4) Non è convenzione adattata dalla community;

Puoi fare quel che vuoi comunque... se ti piace CHAR, usa CHAR...

[badaze]

@jamie04.

Un consiglio. Non mettere nel campo A o C che verrebbe capito solo da Italiano. Preferisci, 0 o 1 che sono internazionali.