Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 11

Discussione: [MySQL] Tipo di dati degli attributi

  1. #1
    Utente di HTML.it
    Registrato dal
    Sep 2012
    Messaggi
    400

    [MySQL] Tipo di dati degli attributi

    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.

  2. #2
    Utente di HTML.it
    Registrato dal
    Jun 2008
    Messaggi
    1,192
    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.

  3. #3
    Utente di HTML.it L'avatar di badaze
    Registrato dal
    Jun 2002
    residenza
    Lyon
    Messaggi
    5,072
    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...
    Ridatemi i miei 1000 posts persi !!!!
    Non serve a nulla ottimizzare qualcosa che non funziona.
    Cerco il manuale dell'Olivetti LOGOS 80B - www.emmella.fr

  4. #4
    Utente di HTML.it
    Registrato dal
    Jun 2008
    Messaggi
    1,192
    Quote Originariamente inviata da badaze Visualizza il messaggio
    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.

  5. #5
    Utente di HTML.it L'avatar di badaze
    Registrato dal
    Jun 2002
    residenza
    Lyon
    Messaggi
    5,072
    Da non dimenticare.... il but unix del 2038 !
    Ridatemi i miei 1000 posts persi !!!!
    Non serve a nulla ottimizzare qualcosa che non funziona.
    Cerco il manuale dell'Olivetti LOGOS 80B - www.emmella.fr

  6. #6
    Utente di HTML.it
    Registrato dal
    Jun 2008
    Messaggi
    1,192
    Quote Originariamente inviata da badaze Visualizza il messaggio
    Da non dimenticare.... il but unix del 2038 !
    L'importante è che non ne soffrano anche le tue calcolatrici

  7. #7
    Utente di HTML.it L'avatar di badaze
    Registrato dal
    Jun 2002
    residenza
    Lyon
    Messaggi
    5,072
    Per fortuna pochissime hanno un orologio e quelle che ne hanno uno non mi sembra abbiano superato quello del 2000.
    Ridatemi i miei 1000 posts persi !!!!
    Non serve a nulla ottimizzare qualcosa che non funziona.
    Cerco il manuale dell'Olivetti LOGOS 80B - www.emmella.fr

  8. #8
    Utente di HTML.it
    Registrato dal
    Sep 2012
    Messaggi
    400
    perché CHAR è la peggiore fra le scelte?

  9. #9
    Utente di HTML.it
    Registrato dal
    Jun 2008
    Messaggi
    1,192
    Quote Originariamente inviata da Jamie04 Visualizza il messaggio
    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...

  10. #10
    Utente di HTML.it L'avatar di badaze
    Registrato dal
    Jun 2002
    residenza
    Lyon
    Messaggi
    5,072
    @jamie04.

    Un consiglio. Non mettere nel campo A o C che verrebbe capito solo da Italiano. Preferisci, 0 o 1 che sono internazionali.
    Ridatemi i miei 1000 posts persi !!!!
    Non serve a nulla ottimizzare qualcosa che non funziona.
    Cerco il manuale dell'Olivetti LOGOS 80B - www.emmella.fr

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2017 vBulletin Solutions, Inc. All rights reserved.