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

Bueno. necesito colocar 100.000 fotos jpg de 5 kb cada una en una base de datos access, MySQL o Interbase 6.0 o Firebird 1.5.

La idea loca es: las fotos tiene por nombre el número de cédula de las persona de la foto, un número único que oscila entre 100.000 y 130.000.000 por rangos. si creo una base de datos por cada grupo de 100.000 números (eso no implica que sean 100.000 fotos por cada grupo, a lo sumo 5.000) y en el aplicativo, en un datamodule creo igual cantidad de databases y para cada tabla de cada database creo un TTable????

Este esquema se puede volver muy lento? ¿Es difícil de manejar? ¿Alguien lo ha hecho? ¿COMO SE MANEJAN LOS CONSOLIDADOS?

BUENO, LA IDEA ES NO TENER LAS 100.000 FOTOS EN ARCHIVOS, PUES EL APLICATIVO LO MANEJAN VARIOS USUARIOS, BACHILLERES QUE PRESTAN EL SERVICIO MILITAR EN LA INSTITUCION Y QUE EN OCACIONES SE METEN CON LOS ARCHIVOS Y LOS BORRAN, EL CUENTO ES QUE DEBO OFRECER A MI CLIENTE MAYOR SEGURIDAD EN DICHOS ARCHIVOS Y COLOCANDOLOS AFUERA NO ESTAN MUY SEGUROS.

UNA PRUEBA EN INTERBASE 7.0, CON 20.000 FOTOS ME ARROJÓ UNA BASE DE DATOS DE 63 GB, LUEGO SE 100.000 SERÍA INMANEJABLE...

AAAAAYYYYYYUUUUUUDDDDDDAAAAAA :confused: :confused: :confused: :(

Pues si...es loca.

Si la BD esta en un servidor independiente dentro de un dominio de Windows, puedes restringir el acceso a los archivos. De hecho, si hay muchos lios con los estudiantes es por fallas en la administracion.

Lo que necesitas es un esquema de relacion uno-varios. Algo como

Tabla Grupos

Id Nombre
1 Grupo1
2 Grupo2

Estudiantes

Id IdGrupo Imagen (Ruta/Blob)
1 1
2 1
3 2

Te recomiendo mejor ir con las fotos afuera, en parte porque sale grande el archivo pero ademas es un duplicado de la informacion. La informacion estructurada en la BD, la no estrucutrada donde corresponda!

Hola,

Mirá, yo te puedo responder en cuanto a la BD si es Firebird. Tengo desarrollado un sistema de escribanía que hace algo similar a lo que vos decís y al principio tuvimos ese problema de tamaño. Lo que hicimos fue comprimir el formato de imágen a JPG y de esa manera disminuimos a la mitad la BD, obviamente con una perdida aceptable de calidad en la fotografía.
Hay que recalcar que Firebird también tiene la posibilidad de manejar múltiples archivos por BD, aunque nunca he llegado a tanto.

En cuanto a tus preguntas sobre lentitud no las puedo responder, puesto que nosotros tenemos todo un esquema que nos ayudan a evitar los controles DB Aware y aceleran muchísimo la manipulación de datos.
Creo que lo vitál aqui es el diseño de tu BD (léase índices, tipos de campos, relaciones, etc.)

Lo que me llamó la atención son los resultados de las pruebas que dijiste... 63 gb??? mmm, salado...

Obviamente se puede manejar las imagenes dentro de la BD. Sin embargo, luego de haber experimentado con un programa similar a este thread, la cosa es muy complicada dentro. Por ejemplo, los backups normalmente son de datos y no con los archivos (nos toco backups que ni cabian en un mismo CD...). Asi que hay que analizar que ventajas reales puede dar esa configuracion. Puede ser muy util por la portabilidad; pasar la BD pasa toda la informacion. Pero la administracion de imagenes es mas simple en el sistema de archivos, definitivamente.

Hola,

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.

Creo que por rutas es mejor
 

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ó.... :D



SHRK____/(
( (

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!!! :D

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

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

Hola,

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.

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.

Soy partidario de que las imágenes estén en la Base de Datos (salvo muy contados casos -muy particulares-).
La idea de la dos Bases de Datos me parece muy buena.

CONSEJO: Elimina Access de esa lista!! Hace daño verla ahí...;)

Tienes toda la razón, desafortunadamente el cliente la pidio en access para poder accederla de manera facil en su equipo con Access 2003


Bueno, cosa aparte.

Ya logre insertar 150.000 fotos en una base firebird 1.5 y el archivo subio a 201 mb.

para poderla accesder desde la red que debo configurar?

Sergio

¿Y se puede saber que impide que alguien borre toda la base de datos si pueden borrar los archivos .jpg? El hueco de seguridad sigue ahi: la idea es que no puedan borrar archivos importantes cuando les de la regalada gana.:rolleyes::rolleyes::rolleyes:

Con un servidor de datos (como los citados), los clientes no tienen acceso directo al (a los) archivo físico de la base de datos, ya que sólo el proceso servidor tiene ese privilegio. Es más, los clientes pueden desconocer todos los detalles del sistema de archivos donde se almacena la información y tener negados los derechos de acceso al mismo. Esa es la diferencia.

Saludos.

Sql 2005, hasta archivos mp3 he guardado...! (como bin)
No dudes en usarlo funciona y muy bien

Hola.
En este hilo ya se ha platicado un poco de este tema.
-
Saludos.

Tengo una idea, si el problema es que algun usuario borre alguna foto, y debido a la cantidad de imagenes seria imposible darce cuenta si alguien borro algo no?

Tons por que no guardas el nombre de la imagen en la DB, ojo dije nombre no ruta completa! y los archivos de imagenes los metes a un archivo comprimido!

Me explico, yo utilizo el compresor 7-zip que es igual que el winzip o winrar pero es gratis y lo puedes manejar desde linea de comando diciendole que archivo quieres que extraiga de un archivo comprimido.

puee bajarte el compresor en un zip desde aquí, no necesariamente necesitas el setup instalador.

voto por 2 bases de datos
 

Desde la aplicación que ataque la base de datos, no dejes eliminar las fotos, solo deja poner fecha de Baja y Usuario que ha entrado en la aplicación.

Si tienen fechas de Baja, no enseñes la foto, es como si no estuviera, pero si ha habido un erros, al darla de baja, puedes entrar como administrador y volverla a dar de alta.

Tienes que controlar en la aplicacion que ataca la base de datos, Los Usuarios i permisos de los Usuarios.
En las tablas jo pongo, Fecha de Creación Registro y Usuario Creacion, Fechas de ultima Modificacion Registro y Usuario que Modifica

Saludos