FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
consejo para mostrar y guardar imagenes
hola foro quiero saber su opinion para implementar una cosa, yo utilizo delphi 5 e interbase 6.
Tengo una base de datos de automoviles, mi idea es tener algunas imagenes de los autos, ahora? me conviene guardarlas en la base de datos y mostrarlas o me conviene indicar en la bd el path donde estan las imagenes y despues q el programa las muestre. Y ya que estamos les hago otra consulta, me e bajado varios iconos para el programa el tema es que los iconos lindos ocupan 345k, es un monton o no? yo los q tengo de 20 x 20 en bmp ocupa 1 o 2 k, ustedes como lo usan eso? Saludos Última edición por Patricio fecha: 19-06-2008 a las 20:19:05. |
#2
|
||||
|
||||
Hola Patricio,
El tema fue tratado en varias ocasiones, si buscas en los foros encontrarar dichos hilos. La respuesta más honesta que se me ocurre es: Depende. Cada cosa tiene sus ventajas y desventajas. Y al final lo que determina que es más conveniente son los requisitos/funcionalidades del sistema y hasta las restricciones del proyecto. Guardar imagenes en DB no es una buena alternativa si lo vemos desde el punto de vista del espacio o tamaño puesto que esto hace crecer mucho a la BD. Por otro lado, tenerlas almacenadas en una DB es un medio relativamente seguro. Si se opta por guardar el Path necesitaremos tener el acceso a dicho directorio. Y aqui hay que considerar de que si el sistema será usado en red, habrá que hacer compartido dicho directorio. Por otro lado, una pequeña metida de pata y ¡puf! desaparecen las imagenes o hasta el directorio mismo y las cosas se van a diablo... Como ves, hay muchas cosas que considerar. Yo sólo te muestro una punta del iceberg. Deberás analizar tu situación y las disponibilidades técnicas a las que te ves sometido para determinar que es más adecuado para ti. Saludos, |
#3
|
||||
|
||||
Cita:
¿Tan mal manejan los motores los campos BLOB? // Saludos |
#4
|
||||
|
||||
Cita:
Y es como dices, al final puede que el tamaño termine siendo relativamente igual (o similar, creo que sería mejor decir). Como bien señalas, el mayor delito es hacer ese select. Por lo menos yo no he tenido problemas con Firebird 1.5 y los BLOB. Al menos hasta ahora. No tengo una base de datos enorme para hacer la prueba... pero creo que en algún punto es posible que sean perceptibles ciertos "efectos". En lo personal, considero que cuanto menos pese la base mejor. Más fácil es "mantenerla". Asi lo veo yo. Una pregunta que se me cruza por la cabeza ¿Es lo mismo hacer un backup y/o un restore de una base de datos que no almacena nada en BLOB de otra que si tiene? Si alguien puede explicarme ese aspecto sería muy útil para el hilo. Como yo he dicho antes, esto requiere de estudio. Lo primero y fundamental: ¿Para qué y porqué se desea guardar imágenes? ¿la tabla en donde estarán guardadas tienen mucho movimiento? ¿Se guardarán muchos registros? ¿Sólo se emplearán de vez en cuando?¿Cambiarán las imagenes con mucha frecuencia? ¿Hasta que punto son independiente los datos asociados a las imagenes de éstas? ¿Puede existir la posibilidad de trabajar con datos puros sin tener que llevarnos las imágenes a cuestas? Esas son las primeras preguntas que hay que hacerse y es por ello que considero que el problema pasa más por las necesidades, requisitos y disponibilidades técnicas antes de el tamaño final. Roman, haz dicho bien en decir que al final de cuentas es lo mismo. En eso te doy la razón. Pero he aquí el asunto de que son otras cosas las que pueden influir. Por ejemplo, yo me imagino a aquel "cliente" con su win 98, disco de unos pocos gigas, y poca RAM... y si le sumo la posible frecuencia de uso ¡puf! menos... Por poner un ejemplo... supongamos que en un centro de radiografía desean guardar cada foto que poseen, quieren dijitalizar. Y el dueño no quiere jugarse con un disco más grande y/o algún otro equipamiento nuevo (si desean pueden considerar incluso una PC entera). Modestamente digamos unas 50 imagenes por día... a la semana son 350... por más PNG que sean... cada kb suma y a la larga ese peso puede resultar más "molesto" que sólo tener datos crudos y estar viendo las placas a mano. Aqui lo correcto es ofrecer otra alternativa, buscarle la vuelta... tal vez buscar y convencer al cliente de que es mejor inicialmente llevar información cruda, y continuar con las placas a mano. Y en una segunda etapa del proyecto, ya avanzado, y con el debido recupero de inversión y renovación de equipo llevar a cabo la dijitalización. No se si me explico y si el ejemplo que doy es el más adecuado. Considero que el aporte de otros foristas puede enriquecer este hilo. Saludos, |
#5
|
||||
|
||||
Púes yo después de mucho probar con archivos compartidos en la red, después de lidiar con las diferentes formas de interactuar entre versiones de windows (por ejemplo que Windows XP home no guarda contraseñas de red, mientras el Professional si lo hace) hice unas pruebas en Firebird 1.5 y guarde un buen numero de imagenes en una base de datos, desde ese día sigo usandola y no regreso al manejo de archivos... el tamaño en que crecio la base de datos es igual al tamaño que ocupan en disco duro las imagenes, la velocidad es buena.... creo que es importante hacer unas cosas para mejorar el rendimiento por ejemplo, crear una bd única para las imagenes donde guardo adeás de las imagenes un campo que la relaciona y una descrpción de la imagen...
__________________
"Como pasa el tiempo..... ayer se escribe sin H y hoy con H" |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Consejo para impresion | lbidi | Impresión | 2 | 02-08-2006 03:58:22 |
Consejo imagenes | fjcg02 | Gráficos | 4 | 12-12-2005 12:04:30 |
Guardar Imagenes | escarlete | Gráficos | 1 | 11-10-2005 18:57:47 |
Guardar Imagenes en MySQL | DJ VMan | MySQL | 5 | 14-08-2003 14:27:08 |
Guardar imagenes en una tabla | Jordy | Conexión con bases de datos | 3 | 04-07-2003 02:53:35 |
|