Imagenes en Firebird

[[ArdiIIa]]

Pues siento discrepar jhonny, pero yo personalmente no veo ningún inconveniente ni desventaja a la hora de tratar las imágenes en una BD.
Yo nunca encontré problema alguno con las BD que llevan imágenes. Se aprovecha la gran ventaja de firebird de tener toda la información compactada en un "solo fichero" (si es el caso), y no tienes archivos "perdidos" en carpetas.
A la hora de un Backup/Restore, supongo que también habría que hacerlo con los ficheros contenidos en una carpeta.
En cuanto al tamaño de la BD, ya se habló mucho de las cantidades y límites soportadas por Firebird que consecuentemente serían las del propio sistema que soporte a Firebird.
Tampoco veo ningún problema para "procesar" las imágenes a la hora de que estas fueran proyectadas vía web.....

En fin, llevo muchas BD con imágenes y nunca he tenido problemas cuando estas son tratadas... por lo cual apoyo ese sistema.

- Crear una tabla independiente con solo las imágenes y un campo llave.

Esta me parece buena alternativa, de este modo la table que contiene los datos podría ir mas ágil y solamente mostraría la imagen cuando realmente fuera necesario.

[marcoszorrilla]

Crear una tabla indendiente con imágenes es algo que he hecho para aumentar el rendimiento en las consultas, que la mayor parte de las veces no necesitan las imágenes.

Un Saludo.

[jhonny]

Desde luego que guardar imagenes en la base de datos directamente, también tiene sus ventajas, tal vez en este caso (El de guardar archivos multimedia en una BD), soy mas paranoico, la capacidad de Firebird para guardar y manipular mucha información no la pongo en duda, pero dejar todo en un solo archivo, me causa algo de desconfianza... aunque bueno, en ultimas, todos los datos de la compañía siempre están en un solo archivo... no se, en lo personal y teniendo en cuenta sus comentarios, tal vez pueda cambiar de opinión, luego de hacer mas pruebas con respecto a este tema.

[Kipow]

Yo lo hago actualmente a nivel del S.O. por ejemplo tengo clientes que tienen un aprox de 20,000 articulos cada uno con 1 o mas fotos, digamos que su tamaño promedio rondara los 15KB creo que seria demasiada info para cargarla a la base actual y esto implicaria demasiada info a la hora de un backup/restore incluso pesado para las consultas ( a menos que lo hiciera como sugiere marcos que no me suena muy bien la opcion de guardarlo en otra tabla). yo me decantaria con hacerlo dentro de la base ya con la version 2.5 que me permitira leer informacion de otras bases de datos desde mis procedimientos y trigguers. por el momento voto por hacerlo afuera.

[[RONPABLO]]

Yo lo hago en una Bd (pero independiente), por varios motivos:
1. El principal y más molesto, evitar lidiar con versiones de Windos XX Home.
2. El mal rendimiento al hacer copia de seguridad de muchos archivos (mil, 15 mil 200 mil imágenes copian más rápido en un solo archivo que una a una en sus debidas carpetas).
3. integridad referencial (o emularla), es más fácil controlarla desde la bd que por archivos.

[[RONPABLO]]

Y la mejor solución que podría existir es que Firebird tuviera una opción algo así como LoadBlobFromFile, de forma tal que en un query yo pudiera hacer algo como:

Código SQL [-]
   select t.nombre, t.telefono, loadBlobFromFile(t.rutaImagen) from tabla t

Ahí verán si creamos una UDF que haca eso... (aunque siempre me quedo en el punto de como cargar el campo blob sin usar ni DBX, IBX ni ningún componente que requiera una DLL)

[Kipow]

Y como haria generar una instruccion asi:

Código SQL [-]
insert into table (campo1, campoblob, campo3)
values (..............)

prefiero no liarme con los blob.

[Nasca]

Empezado por RONPABLO

Y la mejor solución que podría existir es que Firebird tuviera una opción algo así como LoadBlobFromFile, de forma tal que en un query yo pudiera hacer algo como:

Código SQL [-]
   select t.nombre, t.telefono, loadBlobFromFile(t.rutaImagen) from tabla t

Ahí verán si creamos una UDF que haca eso... (aunque siempre me quedo en el punto de como cargar el campo blob sin usar ni DBX, IBX ni ningún componente que requiera una DLL)

Yo tengo una base de datos que carga los faxes recibidos desde hilafax (a través de un scripts php para consola) para que sean procesados por un faxmaster. El caso es que después de años recibiendo faxes, la base de datos ya pesa un poco, por eso consideré una opción como la tuya para no tener que lidiar con los permisos en un servidor samba y los problemas que eso conllevaría a la hora de una conexión remota, ya que antes usaba zebedee, aunque ahora me he pasado a terminal server por rendimiento.

Mi ventaja es que solo necesitaría cargar una imagen por vez. El problema que mas me preocupa es el tema de la seguridad. No obstante la UDF rFunc tiene algunas funciones que pueden servir como guía:
http://rfunc.sourceforge.net/rfunc.htm

En la sección de funciones "File". Otra opción podría ser codificar en la función UDF el fichero con alguna codificación MIME y cargar un string (comprimido??) que podríamos decodificar en el cliente.

Por cierto, como complemento a esto y para evitar el acceso directo a disco con sentencias SQL, he pensado que lo mejor sería un script que haga limpieza de los archivos una vez borrados en la base de datos la información que los complementa.

De todas formas este sistema solo tiene sentido cuando no hay interacción del usuario a la hora de cargar archivos, todo está automatizado, y el usuario solo los procesa añadiendo información. El tema se complica en los casos mas comunes en que el usuario deba crear y gestionar los archivos de forma directa. En este caso en la mayoría de las ocasiones, sobre todo cuando hay mucha diversidad en el dato/s a guardar) he optado por una ruta automática: "CAMINO"+"CLAVE del REGISTRO" sobre un servidor de archivos.