¿Almacena la imagen en la base de datos directamente o como datos base64?

El método común para almacenar imágenes en una base de datos es convertir la imagen en datos de base64 antes de almacenar los datos. Este proceso boostá el tamaño en un 33%. Alternativamente, es posible almacenar directamente la imagen como un BLOB ; por ejemplo:

 $image = new Imagick("image.jpg"); $data = $image->getImageBlob(); $data = $mysqli->real_escape_string($data); $mysqli->query("INSERT INTO images (data) VALUES ('$data')"); 

y luego mostrar la imagen con

  

Con este último método, ahorramos 1/3 de espacio de almacenamiento. ¿Por qué es más común almacenar imágenes como base64 en bases de datos MySQL?

ACTUALIZACIÓN: hay muchos debates sobre las ventajas y desventajas de almacenar imágenes en las bases de datos, y la mayoría de las personas creen que no es un enfoque práctico. De todos modos, aquí supongo que almacenamos la imagen en la base de datos y discutimos el mejor método para hacerlo.

  • Pro base64: la representación codificada que maneja es una cadena bastante segura. No contiene ni caracteres de control ni comillas. El último punto ayuda contra los bashs de inyección de SQL. No esperaría ningún problema simplemente agregar el valor a una cadena de consulta SQL “codificada a mano”.

  • Pro BLOB: el software del gestor de bases de datos sabe qué tipo de datos debe esperar. Se puede optimizar para eso. Si almacenase base64 en un campo TEXT, podría intentar construir algún índice u otra estructura de datos para él, lo que sería muy útil y útil para datos de texto “reales” pero inútiles y una pérdida de tiempo y espacio para los datos de imagen. Y es la representación más pequeña, como en el número de bytes.

Sostengo que las imágenes (archivos) NO suelen almacenarse en una base de datos64 codificada. En cambio, se almacenan en su forma binaria sin procesar en una columna (archivo) binaria (blob).

Base64 solo se usa como mecanismo de transporte, no para almacenamiento. Por ejemplo, puede incrustar una imagen codificada en base64 en un documento XML o un mensaje de correo electrónico.

Base64 también es compatible con la transmisión. Puede codificar y decodificar sobre la marcha (sin conocer el tamaño total de los datos).

Mientras que base64 está bien para el transporte, no almacene sus imágenes codificadas en base64 .

Base64 no proporciona sum de comprobación ni nada de valor para el almacenamiento.

La encoding Base64 aumenta los requisitos de almacenamiento en un 33% en un formato binario sin formato. También aumenta la cantidad de datos que deben leerse del almacenamiento persistente, que sigue siendo, en general, el mayor cuello de botella en la informática. En general, es más rápido leer menos bytes y codificarlos sobre la marcha. Solo si su sistema está vinculado a la CPU en lugar de a IO, y está generando regularmente la imagen en base64, entonces considere almacenarla en base64.

Las imágenes en línea (imágenes codificadas en base64 incrustadas en HTML) son un cuello de botella: envían un 33% más de datos por cable y lo hacen en serie (el navegador web debe esperar las imágenes en línea antes de que pueda terminar de descargar la página HTML).

Si aún desea almacenar imágenes codificadas en base64, haga lo que haga, asegúrese de no almacenar datos codificados en base64 en una columna UTF8 y luego indexarlos.

Recomiendo mirar bases de datos modernas como NoSQL y también estoy de acuerdo con la publicación de user1252434 . Por ejemplo, estoy almacenando unos PNG de <500kb como base64 en mi db Mongo con un conjunto binario en true sin ningún golpe de rendimiento. Mongo puede usarse para almacenar archivos de gran tamaño, como videos de 10MB, y puede ofrecer grandes ventajas de ahorro de tiempo en las búsquedas de metadatos para esos videos, ver almacenamiento de objetos grandes y archivos en mongodb .