Diseñar base de datos con objetos archivos de imagen vinculados. Tamaño de las aplicaciones
Espero puedas resolverme este "gran problemazo" en el que me hallo inmerse, debido, entre otras cosas, a que no soy un usuario muy experto en Access. El tema es que tengo que diseñar una bbdd con alrededor de unos 12000 registros. Vale. Lo difícil es que, cada registro, contiene un campo de ObjetoOle, en el que va vinculada/incrustada un archivo de imagen. Estos archivos de imagen, para que la aplicación (o el archivo ".mdb") no se extienda mucho, los he reducido al máximo, alrededor de unos 20 Kb es lo que he conseguido. Pero claro, te puedes figuarar, yo ya he hecho cuentas y, me dan: si alrededor de 400 fotos me ocupan 250 Mb, puf, ¿podrá soportar la aplicación "tirar" de casi 3 o 4 Gb en su contenido? Amigo, no sé si habrá alguna otra forma de llevar a cabo esto, pero yo, la verdad, no le veo solución, sobre todo a que, vale, ahora me va bien, pero cuando llegue a ese número de registros referidos no sé cómo va a ir el ordenador ni la aplicación. Y, por otro lado, es evidente, de qué manera la voy a distribuir. No sé. Estoy perdido. ¿Me puedes dar otra solución?, quizá otra forma de diseñarlo... O si no es posible hacerlo a fin de cuentas.
Respuesta de ragys2001
1
ACCESS no es conveniente utilizarlo sobre 1000 o 2000 registros, recuerda que esta disenyado para pequenyas aplicaciones. Con 12000 se te va a las pailas (se caería). Como te comentaba hay dos soluciones que procedo a explicarte a continuación:
1. No hacerlo en ACCESS sino que en SQL Server, por ejemplo. Con SQL Server tienes el suficiente soporte para almacenar todas las fotografías que quieras. Estadisticamente, SQL Server esta disenyado para soportar y mantener sobre los 100000 registros. Así es que con 12000 registros más las fotos, estarías al borde de la capacidad total del SQL Server. (Esta solución no creo que sea la que quieres).
2. Utilizando ACCESS, puedes hacer la referencia de la foto en algún campo de la base de datos. Aque me refiero con eso... En vez de tener un campo tipo OLE en alguna tabla, puedes reemplazarlo por un campo de texto normal, con longitud máxima de 255 (o 254). ¿Qué pondrías en ese campo?. La respuesta, es que pondrías la ruta (path) de donde esta almacenada la foto en el disco duro. Por ejemplo, la foto ernesto.jpg, esta en:
C:\Fotos\ernesto.jpg
En la base de datos, en el campo de la tabla (en vez de tener la foto) almacenas la ruta de la foto, es decir, (como es del tipo texto) tendrías almacenado "C:\Fotos\ernesto.jpg".
(Obviamente la foto no la guardas en la base de datos, sino que la guardas en el disco duro solamente)
Así tendrías una base que pesa significativamente menos que la que pretendías. (Creo que esta es la mejor solución)
Para capturar la ruta (path), es sencillo, y con un poco de VB, puedes cargar la foto en algún cuadro de imagen... no deberías tener problemas para poder hacerlo...
Espero que la respuesta sea lo que esperabas, suerte.
PD: Si tienes otra pregunta, hazme una nueva... please, necesito los puntos ;)
1. No hacerlo en ACCESS sino que en SQL Server, por ejemplo. Con SQL Server tienes el suficiente soporte para almacenar todas las fotografías que quieras. Estadisticamente, SQL Server esta disenyado para soportar y mantener sobre los 100000 registros. Así es que con 12000 registros más las fotos, estarías al borde de la capacidad total del SQL Server. (Esta solución no creo que sea la que quieres).
2. Utilizando ACCESS, puedes hacer la referencia de la foto en algún campo de la base de datos. Aque me refiero con eso... En vez de tener un campo tipo OLE en alguna tabla, puedes reemplazarlo por un campo de texto normal, con longitud máxima de 255 (o 254). ¿Qué pondrías en ese campo?. La respuesta, es que pondrías la ruta (path) de donde esta almacenada la foto en el disco duro. Por ejemplo, la foto ernesto.jpg, esta en:
C:\Fotos\ernesto.jpg
En la base de datos, en el campo de la tabla (en vez de tener la foto) almacenas la ruta de la foto, es decir, (como es del tipo texto) tendrías almacenado "C:\Fotos\ernesto.jpg".
(Obviamente la foto no la guardas en la base de datos, sino que la guardas en el disco duro solamente)
Así tendrías una base que pesa significativamente menos que la que pretendías. (Creo que esta es la mejor solución)
Para capturar la ruta (path), es sencillo, y con un poco de VB, puedes cargar la foto en algún cuadro de imagen... no deberías tener problemas para poder hacerlo...
Espero que la respuesta sea lo que esperabas, suerte.
PD: Si tienes otra pregunta, hazme una nueva... please, necesito los puntos ;)
2 respuestas más de otros expertos
Respuesta de etxb
1
Primero de todo... yo no asesoro sobre Access, yo asesoro sobre FileMaker.
Aclarado esto, trabajando en FileMaker y para un caso así tienes una solución.
En vez de almacenar las imágenes dentro de la base de datos puedes "vincular" las imágenes de forma que no están físicamente dentro y por tanto no desmadran el tamaño.
El único condicionante es no cambiar las imágenes de la carpeta en la que estén inicialmente dado que entonces no serían encontradas.
Ignoro si en Access se puede hacer alguna cosa así.
Aclarado esto, trabajando en FileMaker y para un caso así tienes una solución.
En vez de almacenar las imágenes dentro de la base de datos puedes "vincular" las imágenes de forma que no están físicamente dentro y por tanto no desmadran el tamaño.
El único condicionante es no cambiar las imágenes de la carpeta en la que estén inicialmente dado que entonces no serían encontradas.
Ignoro si en Access se puede hacer alguna cosa así.
Respuesta de jorgonzalez
1
Es que no tengo experiencia en grandes bases de datos de access, aunque se por otros, que debería soportarlo sin mayores problemas, siempre y cuando el Server tenga suficiente memoria RAM (1 o 2 GB te sugeriría).
En cuanto a distribuirla, una opción podría ser utilizar el servicio RDP de Windows 2000 Server (o Windows NT 4 Terminal Server, que te permite, a través de un cliente de conexión, ejecutar la aplicación desde el mismo Server, abriendo una terminal o consola remota.
Otra opción podría ser montar Citrix sobre las mismas plataformas, producto que es mucho más poderoso.
Detalles en :
www.citrix.com
Lamentablemente no puede serte de mucha más ayuda, un fuerte abrazo.
[email protected]
En cuanto a distribuirla, una opción podría ser utilizar el servicio RDP de Windows 2000 Server (o Windows NT 4 Terminal Server, que te permite, a través de un cliente de conexión, ejecutar la aplicación desde el mismo Server, abriendo una terminal o consola remota.
Otra opción podría ser montar Citrix sobre las mismas plataformas, producto que es mucho más poderoso.
Detalles en :
www.citrix.com
Lamentablemente no puede serte de mucha más ayuda, un fuerte abrazo.
[email protected]