Se deben cargar archivos o fotos en una base de datos?
 

Me gustaría conocer la opinión de los monstruos acerca de colocar fotos o archivos binarios en los registros de una base de datos.

Saludos

para que tipo de aplicación?

Hola

Este tema se ha comentado ya alguna que otra vez, recuerdo por ejemplo este hilo http://www.clubdelphi.com/foros/showthread.php?t=1955

Aplicaciones web, por supuesto
 

Para aplicaciones web, utilizando cualquier motor de base de datos y php (u otro front end)

Mi experiencia en Sybase en que por cada imagen que agregas a la base esta crece en forma logaritmica y pateticamente , es decir si agregas un blob de 500k , en la base quedaria como de 1.5 megas . Eso por lo menos en sybase , no he probado en mysql .
Saludos .

entiendo eso pero lo primero que se tiene que ver es si vas a manejar una gran cantidad de imagenes, y el nivel de seguridad que piensas aplicar, además de otros factores como el sistema de archivos. si vas a crear la competencia de flickr, y la velocidad no es lo más importante (me refiero al hecho de recuperar la imagen, renderizarla por php y demás) pues usa una base de datos, pero si vas a trabajar con pocas imagenes y lo primordial es el texto, pues usa el sistema de archivos.

Hola,

Todas las aplicaciones que he visto, siempre utilizan el sistema de archivos, es decir nunca se guarda en la base de datos.Actualmente trabajo en app en php y las fotos las accedemos mediante rutas, en cuanto la velocidad es bastante rápido,.

Ahora guardarla en una base de datos, da la impresión que demoraría mas en recuperarla y mostrarla, pero no hablo mas de aquello porque no sé mucho, por mi parte seguiré accediendo via ruta.

Hasta Luego .-

Existe diferencia por el volumn de información o por el tiempo de procesamiento?
 

Así, tu opinión es que si son pocas imágenes y lo primordial es el texto, se use el sistema de archivos.

Ahora, esto va contra la opinión generalizada que se deba utilizar base de datos para almacenar imágenes o archivos binarios.

En cualquier caso, creo que no importa el volumen de información. O por lo menos no debería importar al momento de tomar una decisión.

La verdad es que si algo funciona en grandes volúmenes, debería funcionar mejor en pequeños. No estoy de acuerdo en realizar acciones orientadas al volumen de datos. Si hoy hacemos algo para pocos datos, mañana (si hay suerte sea mala o buena no sé) puede ser que ese volumen se vea incrementado y la aplicación -con un perfil doméstico- periclite bajo los nuevos esquemas.

Los trucos no nos sirven así. Y creo que cualquier workaround siempre resulta perjudicial en el tiempo. Hacer cosas por el volumen... mmm suena interesante pero veo que no es relevante.

Personalmente nunca guardaría imágenes ni archivos en una base de datos, sea cual sea el uso y volumen. Siempre he visto que aumenta el riesgo de que se corrompa, aumente el tamaño de forma exagerada y dificulta, en cierta medida, la labor del programador.

El tema de la seguridad se puede establecer en otros niveles que también resultan efectivos con el sistema de archivos.

Es mi opinión.

Saludos,

Pues yo tengo bases de datos en las que se introducen todo tipo de imágenes en varios formatos, y el rendimiento no ha bajado en modo alguno.

Sería como poner en tela de juicio la propia existencia y cometido de los campos tipo blob, es decir, ¿solamente fueron diseñados para introducir texto? Lo dudo.
Otra cuestión sería ver que tipo de base de datos se utiliza y el rendimiento o prestaciones de la misma con referencia a este tipo de información.

Yo también guardo las imágenes en la base de datos, aunque normalmente uso una base de datos especial para ellas, cuando sé que van a meter una gran cantidad de ellas y/o de gran tamaño.
En otros casos están directamente en la base de datos principal del programa. El rendimiento es igual que si no tuviera imágenes.
La única diferencia es cuando se crea la copia de seguridad, que es un poquito grande, pero nada más.

Acerca de almacenar en la base de datos
 

Una consulta respecto de quienes utilizan la base de datos para almacenar fotos: el servidor de la base de datos se encuentra en la misma computadora que el servidor de archivos a la web?

En mi caso (la empresa donde trabajo) el servidor web siempre es independiente del servidor de bases de datos de la empresa.
Aunque el servidor web es... eso: servidor web, que también accede a las bases de datos del servidor principal de la empresa.
Aquí un pequeño esquema.

No existe diferencia entonces
 

No existe diferencia entre almacenar las imágenes en una base de datos o en el sistema de archivos. El motor de base de datos es SqlServer. Gracias Casimiro por el dato.

Sin embargo, aquí la duda se ha acrecentado, ya que si revisamos los siguientes enlaces, encontramos afirmaciones que el trabajo se vuelve lento.

http://forums.microsoft.com/MSDN/Sho...29610&SiteID=1
http://www.sql-server-performance.co...cid=1&faqid=90

que los obtuve en la búsqueda en google "sqlserver store images check performance".

Para mi que quienes observan bajo rendimiento en esos enlaces, son quienes hacen un

SELECT *

que desde luego bajará el rendimiento a los suelos en caso de haber campos BLOB.

// Saludos

Select * ralentiza en cualquier caso
 

No estarás asumiendo demasiado? Nada me hace pensar que esos usuarios hacen select *.

Sin embargo, si existe una degradación en el tiempo de consulta cuando existen campos blob es por que existen campos blob no porque existen otros campos.

Ahora, recuerdo haber leído en el manual de MySql que para lograr mayor velocidad en las consultas había que evitar el uso de select *. Esa afirmación no se ajustaba estrictamente a los campo blob.

He leído en el sitio de microsoft, el de postgres y el oracle cosas similares.

En cualquier caso, hacer select * ralentiza una consulta (sin importar si tiene o no campos blob).

Posiblemente, pero no veo razón para que el rendimiento baje notablemente por el mero hecho de tener campos BLOB en una tabla. Tal como dice ArdiIIa:



Sí, tienes razón, debí expresarme con más detalle. Con select * quería decir que muy posiblemente esos usuarios que notan una baja considerable en el rendimiento, es porque que incluyen los campos BLOB aun cuando la consulta no tenga un filtro muy fino. No es lo mismo traer los registros de todos los empleados con fotografía incluida, que traer los datos significativos de los empleados y sólo pedir la fotografía de quien nos interese.

// Saludos

Esa base de datos sólo la he usado a modo de pruebas, trabajo habitualmente (siempre) con Firebird.

P.d.: jamás se me ocurriría hacer un "select * from tbloquesea" :)

Hola Casimiro, ¿podrías ampliar esto? ¿Tienes una tabla clientes, y otra fotos_clientes? En todo caso, me llama la atención que decidas usar otra base en caso de haber muchas imágenes siendo que afirmas que el rendimiento es igual.

No es crítica ¿eh? ;) , es sólo que no entiendo bien a qué te refieres.

// Saludos

Bien, me explico: en algunas tablas se almacenen imágenes, por ejemplo, el logo de la empresa (para imprimirlo en los documentos). Sin embargo, las fotos de los artículos van en una base de datos distinta; los documentos escaneados también van en esa otra base de datos, etc. El motivo no es porque sea más o menos lento (o rápido), es por no hacer una base de datos enorme.
Actualmente, casi todos mis clientes hacen una copia de seguridad automática todas las noches, un backup y un restore; esto se hace de la base de datos principal, pero no de la de imágenes, que suele hacerse una vez a la semana o al mes, depende de cada cliente.
¿Por qué?, porque es más rápido hacer el backup/restore y, por supuesto, por mantener las imágenes en una base de datos accesible a Firebird sin que los usuarios tengan que saber dónde está físicamente, no hay que compartir nada a los usuarios, es independiente de sistema operativo, rutas, etc.
Normalmente son bases de datos de varios gigas, (2 a 4 gigas la de datos y 4 a 7 gigas de imágenes), y sería demasiado pesado hacer backup/restore todos los días de eso.
Sin embargo en otros programas y clientes sí que está todo en una base de datos, en estos casos no suelen pasar de 4 gigas en total; eso es todavía fácilmente usable a la hora de hacer backup/restore diarios.
O sea, en una base de datos, dos o las que sea, pero la idea de tener las imágenes fuera de la base de datos me parece, cuanto menos, "extraña" y poco eficiente.