Asesoria Sobre Campo Blob

Andrea Martinez · #1 11-05-2004

el trabajo es este...
consiste en guardar en interbase , es de almacenar 40 imagenes por cada codigounico y hay mas de 20.000 codigos..
40 imagenes* 20.000 codigos = 800.000 imagenes y va creciendo..
todas la imagenes son en formato JPG,

se penso por primera vez en una tabla codigo(almacena el nombre y una identificacion) y una tabla detallegrafico(almaceno todas las imagenes de ese codigo). no se cual es el maximo de imagenes que puedan almacenar.

pero me dijeron que se puede hacer una composición con las 40 fotos o imagenes que ocupen un codigo y guardarlas como una sola imagen en un solo campo Blob y al recuperarla poderlas tratar individualmente, pero no se como.

ya tengo 100000 imagenes ya escaneadas en formato JPG como lo migro a la base de dato formato BLOB

Combat-F2D · #2 11-05-2004

si miras los post ya tratados sobre este tema, veras que una de las opciones que se dan para evitar una crecida muy amplia de la BD, puede ser simplemente crear un campo donde almacenarias el path y el nombre del fichero jpg.

creo recordar que delphi trae un ejemplo de procesado de jpg; no obstante en torry.net seguramente encuentres algun componente bastante completo para el tema que comentas

Andrea Martinez · #3 11-05-2004

ok, voy a revisar, pero la idea es que la imagenes esten dentro de la bases de datos.. no por direccionamiento

GRACIAS..

Julià T. · #4 11-05-2004

creo si buscas en el foro ya han salido temas similares. De todas maneras, en mi web personal tienes código y componentes con funciones tanto para pasar imagenes a campos blob como para cortar (con algo de tu parte también para unir) imagenes jpg.

jachguate · #5 11-05-2004

Depende de para que te sirvan las imágenes... podria no convenirte almacenarlas todas en una composición. Si mas adelante, solo necesitas una imágen, vas a tener que recuperar toda la composición de la base de datos y extraer la imagen que te interesa. Eso desperdiciaría recursos en el servidor, y saturaria innecesariamente la red.

Hasta luego.

Andrea Martinez · #6 11-05-2004

Esa Parte De Composicion Me Interesa, Se Cual Es Lo Negativo Que Hay Que Descargar Toda La Composicion Para Elegir La Correcta, Bien Pero Esa Es La Parte Que Yo Desconosco, Tiene Algun Ejemplo De Composicion ?? Please...yo Estuve Buscando Hilos De Composicion Y No Encontre

guillotmarc · #7 11-05-2004

Hola.

No le veo ninguna ventaja en almacenar 40 imagenes en un solo campo de un único registro. ¿ Porqué no guardas 40 imagenes distintas en 40 registros ?. Total, te va a ocupar practicamente lo mismo en la base de datos, es mucho más sencillo de programar, y cuando quieras recuperar una imagen no tienes que descargarte una composición de 40 (que va a tardar 40 veces más en pasar por la red).

Firebird puede manejar perfectamente 800.000 registros. Yo en tu caso pondría cada imagen en un registro distinto y no me complicaba más la vida.

NOTA: No sé si te he entendido bien, pero no hay ningún formato Blob. Puedes poner tu imagen tal como está (en .jpg) dentro de un campo Blob. Para ello, utiliza el método LoadFromFile del campo en Delphi.

Saludos.

jachguate · #8 11-05-2004

Estoy totalmente de acuerdo con lo dicho por Marc.

Sin embargo, si de todas formas te interesa la "composición", creo que te valdria investigar sobre la clase TCanvas, en especial su método Draw, con lo que podes generar un mapa de bits con la composición, y luego asignarlo a un TJPEGImage (o el formato que te interese) para almacenarlo en el blob.

por cierto, blob es acrónimo de "binary large object", y como ya apuntó también Marcos, no es un formato específico, sino un campo diseñado para almacenar cualquier información binaria. Documentos de word, imágenes, incluso ejecutables y hasta backups de base de datos pueden almacenarse perfectamente en un blob.

Hasta luego.

guillotmarc · #9 11-05-2004

Hola.

Cita:

Empezado por jachguate

Sin embargo, si de todas formas te interesa la "composición", creo que te valdria investigar sobre la clase TCanvas, en especial su método Draw, con lo que podes generar un mapa de bits con la composición, y luego asignarlo a un TJPEGImage (o el formato que te interese) para almacenarlo en el blob.

Aunque funcionaría perfectamente, pero me parece que consumiría mucha CPU y memória (tienes que construir un bitmap enorme que desprués habrá que cambiar de formato para que no ocupe tanto en la BBDD).

Yo simplemente almacenaría una imagen detrás de otra en el campo (es decir no sería una imagen compuesta, sino un flujo de bytes con el contenido de los archivos de imagen), almacenando también en una matriz de 40 enteros la posición de inicio de cada imagen. (Mediante un Stream al que vas alimentando con los archivos de las 40 imagenes).

Para recuperar la imagen deseada, solo tienes que crear un Stream sobre el campo, posicionarte en el inicio de la imagen, y leer los bytes correspondientes hasta el inicio de la siguiente imagen.

Aunque creo que estamos todos de acuerdo, que no hay ninguna razón que justifique esta implementación. Puesto que el inconvieniente de tener que bajar el contenido de 40 imagenes, para acceder a una sola, no parece que quede compensado con la pequeña ganancia de espacio en el archivo de la base de datos (debido a la menor fragmentación interna).

Una estimación de espacio ganado seria : (utilizando un tamaño de página de 4 kb., bastante habitual, que se puede aumentar si las imagenes són muy grandes, para acelerar la lectura de los campos blob)

Registros de imagenes independientes

40 registros de imagenes -> 40 * 4 kb = 160 kb. (asumo que cada registro de datos, ocupa como mínimo una página, cosa de la que no estoy muy seguro, pero vayamos a lo peor).

fragmentación interna de 40 campos blob -> 40 * 4 Kb / 2 = 80 Kb. (asumo que la ultima página de datos del campo blob estará medio vacía).

Registros con 40 imagenes compuestas

1 registro de datos -> 4 kb.
1/2 página de fragmentación interna del único blob -> 2 kb.

Asi pues cada 40 imagenes, ocuparán 236 Kb. más si las almacenamos como registros independientes. O sea, 5.9 Kb. más por imagen. Si las imagenes són de, supongamos un tamaño pequeño de 60 kb., estamos hablando de un 10% que podemos ahorrar en menos registros y menos fragmentación interna.

Gracias al tamaño actual de los discos duros, un ganancia del 10% de tamaño en la base de datos, no me parece que compense el multiplicar por 40 el tráfico de red.

Saludos.