¿Que base de datos almacena imagenes?

huayra · #1 (**permalink**) 10/08/2006, 17:46

Hola amigos....deseo almacenar imagenes...y no que base de datos me soporta..y como..con que lenguaje que plataforma.....por fa yudenme
saludos

Linterns · #2 (**permalink**) 10/08/2006, 19:50

casi todas las bbdd soportan imagenes: mysql, Access, Sql server, Oracle, Posgres etc

August · #3 (**permalink**) 14/08/2006, 18:18

y entre mysql y postgresql, cual es mejor?

BrujoNic · #4 (**permalink**) 14/08/2006, 20:50

Cualquier BD que permita almacenar imágenes ya es buena. Ahora, lo que se debe de tomar en cuenta (según mi opinión), es que entre más grande la imágen, mayor será el crecimiento de la BD, ocasionando tiempos de respuesta muy lentos.

Siempre se va a debatir sobré que es mejor, almacenar las imágenes en la BD o solo guardar un enlace de donde se encuentra almacenada. De esa forma, los tiempos de respuesta serán buenos y las imágenes estarán almacenadas físicamente en una ruta o directorio.

Para otros es mejor almacenar las imágenes dentro de la BD pero ya expuse mi opinión sobre eso.

August · #5 (**permalink**) 14/08/2006, 21:07

Disculpa que moleste Brujonic,

Para los que piensan es mejor usar campos BLOB, cual es su argumento?

Yo tengo ya hecha una conexion a MySQL en la aplicacion la cual usa varias tablas y no pienso migrar toda la aplicacion a PostgreSQL, solamente pensaba migrar la tabla de los archivos en BLOB, pero entonces tendria dos conexiones una para MySQL y otra para PostgreSQL, ¿tu crees que me convenga?

KonstrictorMan · #6 (**permalink**) 23/08/2006, 17:05

Como se te ocurre hacer semejante burrada ??

Si no kieres migrar completamente tu bd a MySQL, entonces lo ke deberías hacer es almacenar las imágenes en disco y en una tabla ingresar las rutas absolutas a donde estén las imágenes...

Cluster · #7 (**permalink**) 24/08/2006, 07:43

Cita:

Para los que piensan es mejor usar campos BLOB, cual es su argumento?

Yo tampoco digo que sea "mejor" ese método .. Sólo expongo sus ventajas (por qué las falencias ya las han comentado: pesado que se vuelve la BBDD = baja de rendimiento en consultas SQL ...):

* Una de ellas sería la de "compactar" los datos que maneja tu aplicación, un "backup" de tu BBDD (dump de tu SQL) ya tendrías todos los datos que maneje tu aplicación separados del "código" de la misma sin tener que ir a respaldar por un lado el "SQL" y por otro algún que otro directorio que contenta esos archivos.

* Si tu aplicación es accedida por vários lenguajes de programación: ejemplo .. PHP por un lado (aplicación "web") y por otro una apliación "de escritorio" tipo Visual Basic .. etc, no tendrías más que usar las mismas sentencias SQL para obtener tus datos (no tendrías que programar o usar en Visual Basic conexiones "FTP" o similares para obtener los "archivos" que estarían en cierto servidor /ruta).

*De esta forma también puedes implementar "de una" .. procedimientos almacenados completos (o simples sentencias SQL) sin involucrar más código del lenguaje de programación que uses: caso típico, .. borras un registro de un archivo en tu BBDD pero también tienes que borrar el archivo en el servidor físicamente con el lenguaje de progrmación que uses.

Pero, como menciono .. todo hay que evaluarlo .. en "promedio" todo el mundo se vá por el lado de almacenar sus archivos en la estructura de archivos del servidor (ruta/directorios) .. tal vez por qué no hay previsión de lo que el sistema puede crecer .. de recursos del servidor o de tamaño promedio de los archivos "binarios" que manejar.

Cita:

Yo tengo ya hecha una conexion a MySQL en la aplicacion la cual usa varias tablas y no pienso migrar toda la aplicacion a PostgreSQL, solamente pensaba migrar la tabla de los archivos en BLOB, pero entonces tendria dos conexiones una para MySQL y otra para PostgreSQL, ¿tu crees que me convenga?

Si tu mismo dices que "no piensas" entonces no uses para nada PostgreSQL. Mira tu servidor el costo de recursos para correr Mysql y PostgreSQL y el de tu aplicación al realizar conexiones simultáneas a estos dos servidores (sin contar que no podrás optimizar las consultas SQL por qué usas dos BBDD diferentes ..).

Lo mejor es que tu mismo te plantees que datos va a manejar tus aplicación e incluso que hagas pruebas reales en tu caso particular. Los "pro's" y "contras" los tienes ya descritos .. ahora decide tú.

Un saludo,