¿Está almacenando la imagen en la base de datos directamente o como datos base64?

Question

El método común para almacenar imágenes en una base de datos es convertir la imagen a datos base64 antes de almacenar los datos. Este proceso aumentará el tamaño en un 33%. Alternativamente, es posible almacenar directamente la imagen como 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

<img src="data:image/jpeg;base64,' . base64_encode($data) . '" /> 

Con este último método, ahorramos 1/3 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.

Answer 1

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 intentos 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 tiene que 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.

Answer 2

Yo 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 utiliza 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 es también compatible con la transmisión de secuencias. 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 base64 codificadas.

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

La codificación de Base64 aumenta el requisito 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 debe esperar las imágenes en línea antes de que pueda termine 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.

Answer 3

Recomiendo mirar bases de datos modernas como NoSQL y también estoy de acuerdo con user1252434. Por ejemplo, estoy almacenando unos < 500kb PNG como base64 en mi Mongo db 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, consulte storing large objects and files in mongodb.