FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
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
|
#2
|
||||
|
||||
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.
__________________
Marc Guillot (Hi ha 10 tipus de persones, els que saben binari i els que no). |
#3
|
||||
|
||||
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.
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate |
#4
|
||||
|
||||
Hola.
Cita:
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)
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).
1 registro de datos -> 4 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.
__________________
Marc Guillot (Hi ha 10 tipus de persones, els que saben binari i els que no). |
|
|
|