2013-09-27 3 views
6

Ho un'applicazione PHP che memorizza tutti gli account indipendentemente dal fatto che siano attivi o meno in una singola tabella. La tabella ha una colonna denominata "attiva" che è NULL che indica che l'account è attivo o che contiene un hash MD5 che indica che l'account è inattivo.Il miglior tipo di dati MySQL per memorizzare MD5 hash o NULL

Secondo Best practices for efficiently storing md5 hashes in mysql, se la colonna contiene sempre un hash MD5 e mai NULL, quindi BINARY (16) è preferito e CHAR (32) è la scelta migliore successiva. Poiché la maggior parte dei miei account sono attivi e quindi la maggior parte dei valori delle colonne sarà NULL, è meglio usare un tipo di dati diverso come VARCHAR (32)?

+1

sì è possibile .. 'VARCHAR (32)' è preferibile. –

+0

possibile duplicato di [MySQL: quale tipo di dati utilizzare per il campo della password con hash e quale lunghezza?] (Http://stackoverflow.com/questions/247304/mysql-what-data-type-to-use-for-hashed- password-field-and-what-length) –

risposta

12

Non ha senso usare VARCHAR. Gli hash MD5 sono sempre a 128 bit, quindi un CHAR (32) contiene la stringa di cifre esadecimali o BINARY (16) contiene la stringa di byte dopo UNHEX() le cifre esadecimali.

L'utilizzo di NULL è indipendente dalla scelta del tipo di dati. MySQL può memorizzare NULL al posto di una stringa, CHAR o VARCHAR. Ma in realtà, nel formato di riga predefinito di InnoDB, MySQL non memorizza NULL, non memorizza nulla per le colonne che sono NULL.


Riferimento: http://dev.mysql.com/doc/internals/en/innodb-field-contents.html

  • note utili sui NULL:

    Per la terza fila, ho inserito NULL nel CAMPO2 e Campo3. Pertanto nel campo Inizio offset il bit superiore è attivo per questi campi (i valori sono 94 esadecimali, 94 esadecimali, anziché 14 esadecimali, 14 esadecimali). E la riga è più breve perché i valori NULL non occupano spazio.

(sottolineatura mia)

+0

Grazie Bill, in base alla risposta, capisco che se utilizzo CHAR (32) o BINARY (16) e il valore memorizzato è NULL, il mio overhead non è maggiore di utilizzando VARCHAR (32). Grazie e spero che tu abbia ragione! – user1032531

+0

+1 Bill e @ user1032531 Bill significa che è necessario utilizzare CHAR (32) o BINARY (16). e sì il tuo overhead sarà maggiore quando usi VARCHAR perché MySQL ha bisogno di salvare due cortometraggi in più per sapere quanto è grande il tuo VARCHAR.E la chiave di ricerca esatta dovrebbe essere più veloce nelle colonne CHAR quando si definisce il set di caratteri ascii_bin. –

0

Nel codice sorgente MySQL nel file string/ctype-bin.c viene definito il tipo BINARY.

Questo assomiglia al charset C ascii predefinito convertito in binario. Questo dovrebbe essere più veloce di CHAR (32) con il set di caratteri ascii_bin.

Perché è necessario meno tempo per scrivere/leggere il binario e richiede meno spazio su disco negli indici e la memoria e perché il CHAR (32) tipo di dati è di 16 byte più grande

Se si desidera utilizzare questo è necessario utilizzare questo php code

<?php 
    md5 ("password", true); // true returns the binary what is 16 bytes long MySQl BINARY(16) 
?> 
-5

È possibile utilizzare la funzione php md5(); È più efficiente e se chiunque può intercettare i dati quando viene inviato al database, sarà già criptato.

+2

Come risponde la domanda? – mistika