Almacenamiento de datos codificados en base64 como tipo de datos BLOB o TEXT

Uno no debería almacenar datos codificados en Base64 en su base de datos...

Base64 es una codificación en la que los datos binarios arbitrarios se representan usando solo caracteres de texto imprimibles:fue diseñado para situaciones en las que dichos datos binarios deben transferirse a través de un protocolo o medio que solo puede manejar texto imprimible (por ejemplo, SMTP/correo electrónico). Aumenta el tamaño de los datos (en un 33 %) y agrega el costo computacional de codificación/descodificación, por lo que debe evitarse a menos que sea absolutamente necesario.

Por el contrario, el punto central de BLOB columnas es que almacenan cadenas binarias opacas . Así que adelante, guarde sus cosas directamente en su BLOB columnas sin primero codificarlas en Base64. (Dicho esto, si MySQL tiene un tipo más adecuado para los datos particulares que se almacenan, es posible que desee utilizarlo en su lugar:por ejemplo, los archivos de texto como las fuentes de JavaScript podrían beneficiarse de ser almacenados en TEXT columnas para las que MySQL rastrea metadatos específicos de texto de forma nativa; más sobre esto a continuación).

La idea (errónea) de que las bases de datos SQL requieren codificaciones de texto imprimible como Base64 para manejar datos binarios arbitrarios ha sido perpetuada por una gran cantidad de tutoriales mal informados. Esta idea parece estar asentada en la creencia errónea de que, debido a que SQL comprende solo texto imprimible en otros contextos, seguramente también debe requerirlo para datos binarios (al menos para la transferencia de datos, si no para el almacenamiento de datos). Esto simplemente no es cierto:SQL puede transmitir datos binarios de varias maneras, incluidos los literales de cadena sin formato (siempre que estén entrecomillados y escapados correctamente como cualquier otra cadena); por supuesto, la forma preferida de pasar datos (de cualquier tipo) a su base de datos es a través de consultas parametrizadas, y los tipos de datos de sus parámetros pueden ser tan fácilmente cadenas binarias como cualquier otra cosa.

... a menos que esté almacenado en caché por motivos de rendimiento...

La única situación en la que podría haber algún beneficio al almacenar datos codificados en Base64 es cuando generalmente se transmiten a través de un protocolo que requiere dicha codificación (por ejemplo, mediante un archivo adjunto de correo electrónico) inmediatamente después. siendo recuperados de la base de datos, en cuyo caso, almacenar la representación codificada en Base64 evitaría tener que realizar la operación de codificación en los datos sin procesar en cada búsqueda.

Sin embargo, tenga en cuenta en este sentido que el almacenamiento codificado en Base64 simplemente actúa como un caché , al igual que uno podría almacenar datos desnormalizados por motivos de rendimiento.

... en cuyo caso debería ser TEXT no BLOB

Como se mencionó anteriormente:la única diferencia entre TEXT y BLOB columnas es eso, para TEXT columnas, MySQL también realiza un seguimiento de los metadatos específicos del texto (como la codificación de caracteres y colección ) para usted. Estos metadatos adicionales permiten a MySQL convertir valores entre conjuntos de caracteres de almacenamiento y conexión (cuando corresponda) y realizar operaciones sofisticadas de comparación/clasificación de cadenas.

En términos generales:si dos clientes que trabajan en diferentes conjuntos de caracteres deberían ver los mismos bytes , entonces quieres un BLOB columna; si deberían ver los mismos caracteres entonces quieres un TEXTO columna.

Con Base64, esos dos clientes deben finalmente encontrar que los datos se decodifican en los mismos bytes; pero deberían ver que los datos almacenados/codificados tienen los mismos caracteres . Por ejemplo, suponga que desea insertar la codificación Base64 de '¡Hola mundo!' (que es 'SGVsbG8gd29ybGQh' ). Si la aplicación de inserción funciona en el conjunto de caracteres UTF-8, enviará la secuencia de bytes 0x53475673624738676432397962475168 a la base de datos.

• si esa secuencia de bytes se almacena en un BLOB columna y luego recuperada por una aplicación que funciona en UTF-16, los mismos bytes serán devueltos, que representan '升噳扇㡧搲㥹扇全' y no el valor deseado codificado en Base64; mientras que

• si esa secuencia de bytes se almacena en un TEXT y luego recuperada por una aplicación que funciona en UTF-16, MySQL transcodificará sobre la marcha para devolver la secuencia de bytes —que representa el valor codificado en Base64 original 'SGVsbG8gd29ybGQh' como se desee.

Por supuesto, aún podría usar BLOB columnas y realizar un seguimiento de la codificación de caracteres de alguna otra manera, pero eso solo reinventaría innecesariamente la rueda, con una mayor complejidad de mantenimiento y el riesgo de introducir errores no intencionales.