Almacenando valores hexadecimales como binarios en MySQL

Question

Estaba pensando en cómo estoy almacenando contraseñas en mi base de datos: cadenas SHA1 apropiadamente saladas en un campo CHAR (40). Sin embargo, dado que los datos de los caracteres allí son en realidad solo una representación hexadecimal de un número de 160 bits, pensé que sería mejor almacenarlo como BINARIO (20).

CREATE TABLE users (
    password BINARY(20) 
    /* snip */ 
); 

INSERT INTO users (password) VALUES (UNHEX(SHA1('mypassword')); 

mi punto de vista, una ventaja de este enfoque es que se reduce a la mitad el tamaño de ese campo, pero puedo imaginar que probablemente hay algunas desventajas también.

¿Cuál es su opinión?

Answer 1

Utilizamos binarios para un montón de ID diferentes en nuestra base de datos para ahorrar espacio, ya que la mayoría de nuestros datos consistían en estos identificadores. Dado que no parece que necesites ahorrar espacio (ya que solo se trata de contraseñas, no de otro elemento de gran escala), no veo ningún motivo para utilizar el binario aquí.

El mayor problema con el que nos topamos fue constante, molesto, tener datos binarios en la consola (cada vez que seleccionas * oyes un millón de pitidos), y siempre debes seleccionar HEX() o insertar UNHEX (), que es un dolor.

Por último, si mezclas y combinas (por error) binario y HEX/UNHEX y te unes a este valor, puedes hacer coincidir los registros que nunca pensaste.

Answer 2

El ahorro de espacio en el disco duro para almacenar las contraseñas hash como binarias en lugar de varchar probablemente sea insignificante. ¿Cuántos usuarios es probable que tenga en esta tabla? Multiplique eso por la diferencia de espacio entre BINARY(20) y VARCHAR(n) y creo que encontrará que no es un ahorro significativo. Personalmente, preferiría la representación hexadecimal porque al menos puedo escribirla en una consulta si estoy realizando alguna operación ad-hoc durante el desarrollo o escribiendo una prueba unitaria para validar las operaciones relacionadas con la contraseña. Hex es algo más legible que binario si estoy cargando un volcado de datos en un editor de texto, etc. Mi conclusión es que la representación hexadecimal sería más conveniente durante el ciclo de desarrollo.

Answer 3

Aquí está mi desglose:

1. Si utiliza cadenas en lugar de binario, utiliza un campo de longitud fija. Como todos los algos de hash salen a una longitud fija, puedes ahorrarte algo de espacio allí.
2. Como solo hace una comparación de igualdad, no hay necesidad de índices. Los campos binarios no tienen ningún tipo de intercalación o conjunto de caracteres.
3. Los tipos de columnas BINARY no tienen advertencias de almacenamiento extrañas, como BLOBs.
4. Cada carácter hexadecimal representa 4 bits en los 8 (o 7) bits que consume. Esto significa que el almacenamiento binario es dos veces más eficiente.
5. LO MÁS IMPORTANTE: a menos que trabaje en un sistema integrado donde cada byte cuenta, no lo haga. Tener una representación de personaje te permitirá una mejor depuración. Además, cada vez que un desarrollador está trabajando en un problema como este, me pregunto por qué. Cada decisión arquitectónica como esta tiene compensaciones y esta no parece que agrega valor a su proyecto.
6. Siempre puede convertir a BINARY más tarde con un simple script SQL.

En resumen, utilice un campo de texto de longitud fija. No hay ganancia para contar bytes en el mundo actual, especialmente cuando el cambio es fácil de lograr.

Espero que esto ayude.

Answer 4

¿Por qué reinventar la rueda? ¿Por qué no usar CHAR(41) como la tabla `mysql.user 'usa? Es un formato bien conocido, por lo que los futuros mantenedores no se rascarán la cabeza con su esquema especial. Facilítelo a todos simplemente señalando "al igual que las contraseñas de MySQL".

Answer 5

Si desea una manera fácil de almacenar binarios en sql ... puede convertir a hexadecimal antes. Consulte esta página: http://kekoav.com/blog/36-computers/58-uuids-as-primary-keys-in-mysql.html

convertir a hexadecimal, quitarse el "-" y poner "0x" delante de la cadena. Mysql lo entenderá como contenido de bytes.

Ejemplo: INSERT INTO usuarios SET password = 0x1e8ef774581c102cbcfef1ab81872213

Answer 6

Ésta es una vieja pregunta, pero me di cuenta de que nadie ha mencionado la validación de datos como una ventaja para una columna binaria. Específicamente, es posible almacenar un valor no válido en una columna CHAR (40) utilizando caracteres que no son dígitos hexadecimales (0-9, a-f).

Aún puede insertar el valor incorrecto en la columna BINARIO (por ejemplo, si olvida llamar a UNHEX), pero nunca tendrá que considerar leer un valor de la base de datos que no se analiza correctamente.