Esto es una idea loca???????

[kinobi]

Hola,

Empezado por mamcx

...Pero la administracion de imagenes es mas simple en el sistema de archivos, definitivamente.

Es posible, pero también plantea el problema de la seguridad, desde dos puntos de vista contradictorios: por un lado las imágenes quedan fuera de los mecanismos de seguridad que proporcione el gestor de datos, y por otro lado está el asunto de los permisos necesarios (y que tal vez no se tengan) para poder acceder y/o modificar directamente las imágenes en el sistema de archivos. Por no hablar de tener que manejar dos modelos de datos diferentes: el relacional y el propio del sistema de archivos donde se almacen las imágenes; además de posibles problemas de consistencia y coherencia de la información almacenada en la base de datos y en el sistema de archivos.

En mi opinión (personal), es mejor gestionar esa información en la propia base de datos. Otro asunto son los problemas de rendimiento, si es que se presentan.

Saludos.

[sharky]

mira carnal... creo que manejando los archivos fuera de la base de datos te vas a ahorrar tiempo y espacio en la BD, solo almacena la ruta de las imagenes y cuando necesites accesarla, haces una consulta hacia la dirección del archivo en el disco duro y con un LoadFromFile ya la hiciste....


Bueno.... Al menos a mi me funcionó....



SHRK____/(
( (

[quetzal]

mmm, yo he trabajado imagenes (jpg) en campos blob en interbase 6 y 15000
me daban 480 mb con un codigo que habia conseguido en la red y pero despues encontre un componente en la pagina de marteens http://www.marteens.com/imDBJPEG.zip y me lo redujo a 430 mb

checalo con ese componente

si tus imagenes estan en bmp conviertelas a jpg, con el ACDsee las seleccionas todas y le das convertir de formato.

suerte!!!

[sercornejov]

Gracias por responder...

Bueno, pues las imágenes las tengo en JPG y cada una pesa solo 4K (en promedio). Actualmente las manejo por fuera de la DB, pero tengo dos complicaciones:

1. La seguirdad de los archivo de fotos, pues ya han borrado algunos y mi cliente me pide que solucione este "hueco". pues si se necesita saber quien entro en determinado día y la foto no esta.... De nada sirve la aplicación....

2. No se si la definición del campo BLOB tenga mucho que ver con el tamaño de la base de datos... YO LO TENGO COMO:

FOTO BLOB SUB_TYPE 0 SEGMENT SIZE 50

TALVEZ PARA EL TAMAÑO DE LOS ARCHIVOS SE NECESITE OTRA DEFINICION QUE PERMITA QUE LA BASE DE DATOS FUNCIONE MEJOR Y MAS RAPIDO... (MENOR TAMAÑO)

Saludos

[mamcx]

Eso es cierto, Kinobi. Se me acaba de ocurrir un planteamiento alternativo: Que tal usar 2 BD? Una para archivos de imagenes y otra para los datos. La verdad, la sugerencia de tenerlos por fuera es debido a que es menos problematico los backups (los datos son mas volatiles que las imagenes, que cambian poco o nada) . El punto es que en nuestra experiencia con un software en mas de 1500 colegios se veia que las imagenes cambiaban si mucho 1 vez al año (en matriculas) y los datos casi todas las semanas, y la administracion de los backups se volvia muy compleja. Si las imagenes estan fisicamente aparte, no hay que preocuparse porque afecte la velocidad de la BD de datos.

Ahora, el problema esta no tanto en linkear la informacion, que es igual de simple como si se manejara por fuera en el sistema de archivos, sino mas bien en las consultas que deban traer multiples imagenes junto con los datos del alumno. Pero bueno, es solo otra posibilidad...

(A proposito, en Sql Server uno puede hacer Vistas que referencian multiples BD, en Firebird tambien? Porque si es asi, el caso queda resuelto facilmente...)

[kinobi]

Hola,

Empezado por mamcx

Eso es cierto, Kinobi. Se me acaba de ocurrir un planteamiento alternativo: Que tal usar 2 BD? Una para archivos de imagenes y otra para los datos.

Puede ser una buena alternativa. De hecho, InterBase (y Firebird) pueden manejar transacciones contra varias bases de datos. No se elimina la posibilidad de incosistencia de datos (p. ej. imágenes que apunten a datos inexistentes o equivocados en la otra base de datos), pero al menos podemos mantener las operaciones contra las dos bases de datos dentro de las mismas transacciones.

Empezado por mamcx

(A proposito, en Sql Server uno puede hacer Vistas que referencian multiples BD, en Firebird tambien? Porque si es asi, el caso queda resuelto facilmente...)

Estoy algo desenganchado de Firebird, pero hasta la versión 1.5 no era posible hacer lo que dices. Estoy hablando desde el lado del servidor, ya que en el cliente me consta que (en Delphi) existen componentes de acceso que crean el "artificio" de poder acceder a varias bases de datos desde la misma consulta (p. ej. los SQL-Links InterBase para el BDE).

Saludos.