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,