[MySQL] Campo Binary, si può comparare?

[LordSaga640]

Salve,
ho alcune tabelle.
La chiave primaria della riga è un hash MD5 binario di 16 byte.

Volevo sapere se è possibile con questo campo binario fare delle select, controlli di integrità referenziale e join, oppure se posso solo usarlo come storage.

Insomma, le limitazioni di un campo binario.

Grazie in anticipo^^

[geko]

Se l'hash MD5 è quello restituito dalla funzione di MySQL o di PHP è una stringa esadecimale, per cui credo sia meglio memorizzarla in un campo CHAR(16) e non BINARY. In questo modo è meno oneroso per il DB e più facile da maneggiare.
Ad ogni modo è sempre meglio utilizzare un identificatore di tipo INT come PRIMARY KEY, anche se può sembrare superfluo

[LordSaga640]

[supersaibal]Originariamente inviato da geko
Se l'hash MD5 è quello restituito dalla funzione di MySQL o di PHP è una stringa esadecimale, per cui credo sia meglio memorizzarla in un campo CHAR(16) e non BINARY. In questo modo è meno oneroso per il DB e più facile da maneggiare.
Ad ogni modo è sempre meglio utilizzare un identificatore di tipo INT come PRIMARY KEY, anche se può sembrare superfluo

[/supersaibal]

Allora, tento di rispiegare la domanda.

Posso con un campo binary fare ricerce per campi all'interno della tabella come ho descritto nel post precedente?

[piero.mac]

[supersaibal]Originariamente inviato da LordSaga640
Allora, tento di rispiegare la domanda.

Posso con un campo binary fare ricerce per campi all'interno della tabella come ho descritto nel post precedente? [/supersaibal]

MD5() di solito e' a 32 digit. Viene memorizzato come campo varchar(32) . Il fatto di settarlo BINARY significa che la ricerca del dato sara' case sensitive. Come si dovrebbe fare per lo username.... mentre ha poco significato per una stringa MD5() che e' sempre in minuscolo.

Tra l'altro in mysql 4.1.x non c'e' piu' l'attributo BINARY per i campi, ma bisognera' agire sul COLLATION... es.:

latin general ci
latin general cs

rispettivamente ci = case insensitive e cs = case sensitive.

puoi fare tutte le ricerche che vuoi.

[daniele_dll]

puoi usarlo per fare qualsiasi cosa...ovviamente come ti hanno detto l'md5 è di 32 caratteri (attenzione...l'md5 è di 16 caratteri ma php di default lo restitusice come una stringa esadecimale e quindi diventano 32 caratteri esadecimali quindi se percaso usi php5 e hai impostato che la funzione md5 devi restituirti la forma binaria e non quella esadecimale devi lasciare 16)

per quanto riguarda il tipo di campo ... è come ti hanno detto...ma nel tuo caso...char o binary non ha importanza xche hash è case-insensitive ... metti l'uno o metti l'altro non ha importanza.

inoltre è inutile che lo setti su char se hai campi a lunghezza variabile perché mysql in auto ti trasforma il campo char in varchar ... essendo la tabella già dinamica, forse per evitare controlli aggiuntivi inutili che lo rallentano al momento delle ricerche

[LordSaga640]

No, non hai capito.

Md5 è una funzione che genera un hash a 128 (16byte).
Questo, per una più facile registrazione viene convertito in esadecimale e quindi le cifre raddoppiano (32 byte).

Io ho bisogno di immagazzinare migliaia e migliaia i hash e di prelevarli direttamente in binario. Ogni riga come ho detto è identificata dal suo md5. Però le varie tabelle hanno un controllo referenziale che si basa appunto su questo hash md5 a 16byte.
Conservarli in binario gli hash mi serve per risparmiare spazzio e calcoli perchè lascio la sitrnga primita come è.



Dunque, il campo binary mi sembrava avesse delle limitazioni per il uso, mi potrà dare qualche problema usandolo come primary key?

[LordSaga640]

[supersaibal]Originariamente inviato da daniele_dll
puoi usarlo per fare qualsiasi cosa...ovviamente come ti hanno detto l'md5 è di 32 caratteri (attenzione...l'md5 è di 16 caratteri ma php di default lo restitusice come una stringa esadecimale e quindi diventano 32 caratteri esadecimali quindi se percaso usi php5 e hai impostato che la funzione md5 devi restituirti la forma binaria e non quella esadecimale devi lasciare 16)

per quanto riguarda il tipo di campo ... è come ti hanno detto...ma nel tuo caso...char o binary non ha importanza xche hash è case-insensitive ... metti l'uno o metti l'altro non ha importanza.

inoltre è inutile che lo setti su char se hai campi a lunghezza variabile perché mysql in auto ti trasforma il campo char in varchar ... essendo la tabella già dinamica, forse per evitare controlli aggiuntivi inutili che lo rallentano al momento delle ricerche [/supersaibal]

Non uso php

[daniele_dll]

ah ok...allora dipende dal tuo linguaggio...comunque il principio è lo stesso

[LordSaga640]

[supersaibal]Originariamente inviato da daniele_dll
ah ok...allora dipende dal tuo linguaggio...comunque il principio è lo stesso [/supersaibal]

Bene, quindi ci posso fare anche delle join e tutto il resto.
bene bene, mi ricordavo che i binary si potessero usare solo come storage, ma a quanto pare ricordo male. Forse, mi sembra, che nei binary non si potessero fare delle "like", vabbè, anche se fosse vero non mi darebbe noia.
Grazie ancora.
See you again.^^