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

[Casimiro Noteví]

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.

[semptrion]

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?

[Casimiro Noteví]

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.

[semptrion]

Empezado por Casimiro Notevi

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.

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".

[roman]

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

[semptrion]

Empezado por roman

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.

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).

[roman]

Empezado por semptrion

No estarás asumiendo demasiado?

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:

Empezado por ArdiIIa

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?

Empezado por semptrion

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.

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

[Casimiro Noteví]

Empezado por semptrion

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".

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"

[roman]

Empezado por Casimiro Notevi

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.

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

[Casimiro Noteví]

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.

[semptrion]

El tema de sacar un backup de un sistema de archivos no resulta tecnología de la NASA. Y aunque es un poco extraño, es también manejable en el tiempo y en proceso.

[roman]

Casimiro, gracias por la explicación. Ahora ya entendí

// Saludos