Barrapunto

Hace un tiempo me plantee esa misma cuestión a la hora de integrar los faxes recibidos en el ERP de la empresa. Esta fue la solución:
Base de Datos: Firebird sobre linux
El sistema mediante un scripts en php coge el fax recibido por hylafax, le extrae los metadatos, le asigna un código y lo guarda (en formato tiff) en el servidor en un campo blob.
La base de datos tiene ahora 442 Mb, el primer fax lo recibio el día 2002-09-25 10:15:31.0000, y tiene almacenados 7611 faxes.
Todo va perfecto, se facilita la catalogación y redistribución de los faxes pero lo cierto es que en una pyme no se pueden pedir grandes inversiones en infraestructura informática. Con este tamaño tarda mucho a la hora de hacer las copias de seguridad, y hay que tenerlo en una base de datos independiente de la del ERP, y se pierde la integridad referencial con respecto a las tablas de remitentes (proveedores, clientes) y de trabajadores para redistribución.
Luego para hacer la copia de seguridad hay que copiar un archivo de 409 Megas (el backup, no la base de datos original) que cambia todos los días.
Cuando pasen otros dos años seguramente esté en un nivel intolerable y haya que tomar alguna decisión.

Ahora cuando tengo un entorno intranet controlado pongo los enlaces al servidor de archivos, siempre relativos, nunca almaceno caminos completos.
Por ejemplo los archivos de pedidos, almaceno la ruta general ("\\master\ventas\pedidos") en una tabla de rutas y luego monto el path completo añadiendo la referencia del pedido. Esto me facilita la movilidad de los archivos aunque si cambias el número de pedido tienes un problema, que tampoco es tal con menos de 10 líneas de código, pero que por perro no he contemplado. Ten en cuenta que este sistema no permite el acceso remoto y solo es aplicable a la intranet, aunque esto sería facilmente salvable, al menos en linux, usando fish:// y un servidor ssh en la máquina servidora.

Pero en el caso de los faxes creo que no usaría este modelo ya que solo me permite un control de acceso rudimentario (a través de samba). Ahora montaría un servidor TCP con un protocolo de no más de 10 comandos (lo he mirado en java por la multiplataforma, manejo de hilos, etc) que autentificase contra los usuarios de firebird, determinase sus privilegios de faxmaster, e incluso restringiera a los usuarios no faxmaster en función de la distribución que hagan los faxmaster de los distintos faxes. En el cliente sería cuestión de montar la contrapartida cliente tcp y de sincronizar las gestión de los faxes en las dos direcciones: base de datos con los metadatos, clasificación y distribución y el servidor tcp de manejo de los ficheros. Incluso un sencillo scripts en php o python (por no sobrecargar con la VM de java) podría realizar una sencilla sincronización entre base de datos y archivos para eliminar basura periódicamente, y más en mi caso que pretendo gestionar también los faxes enviados con almacenamiento automático de reportes de envío, todo gracias a las bondades de hylafax, samba, php, linux, ... ;)
La verdad es que montarlo sobre otro sistema propietario sería horrible, por lo pronto mediante samba guardo los fax a enviar con un simple scripts que se lanza cuando imprimes en una pseudo-impresora, y no alcanzo a saber como hacer lo mismo con el servidor CIFS de microsoft.

Bueno, espero que la batallita te haya dado al menos ideas, mi síntesis es que "guardarlo en la base de datos si vas a guardar muchos archivos es la forma fácil pero no creo que sea la mejor".
Yo al contrario de otra persona que te respondio antes, solo lo uso para ocasiones en que no se vayan a almacenar muchos archivos y por ello no merezca la pena complicar el diseño de la estructura servidora y la programación del cliente.
Esto te permitirá también una mayor independencia con respecto a tu SGBD, si la incluyes en el servidor y crece mucho (como parece tu caso que además tiene unas necesidades muy concretas), con el tiempo tendrás que tirar de sistemas SGBD como Oracle y todo por no haber currado un poco más. No se si los clientes van a ser via navegador o aplicaciones de escritorio como en mi caso, pero si son mediante navegador la gestión del sistema es todavía mas sencilla ya que ni siquiera tendrías que tirar de un servidor tcp...

Bueno que me enrollo, suerte.

Plas, plas, plas,..., plas
he estado leiendo todos los comentarios buscando aquel que haria lo más logico, una tabla de rutas!
puedes cambiar de servidor, puedes tener rsync para las copias de archivos.
Y el tema de seguridad de los archivos, igual supongo?
de los archivos el propietario el SGBD y enviar una copia a la aplicación cliente, o linkar en un espacio del usuario el archivo, o algo para que qualquiera no tubiera acceso a los archivos.

Yo he optado por modificar directamente los scripts sh de entrega de hylafax, desde el mismo llamo al scripts en php pasándole la ruta del fax a procesar.
Incluso hacer que funcione para cargar masivamente un directorio es realmente fácil.

Este tipo de proyectos son difíciles de generalizar y además implican muchas piezas distintas:
* SGBD: para mí sin duda Firebird
* Un lenguaje para los scripts de procesamiento: php | perl | python | ..., cualquiera con acceso a Base de datos serviría.
* Hylafax: era obvio pero...
* Samba para la pseudo-impresora que convierta a Pdf los archivos de una impresora Postscript y llame a otro scripts para guardar el fichero resultante.
* Servidor smtp: ya es una exigencia de hylafax, pero además lo sería para notificar a usuarios y guardar comprobantes de envio.
* Servidor TCP con protocolo específico: en este caso se usaría, python, perl o java.

Además los clientes deberían ser muy específicos.

Resumiendo que es un proyecto no tan difícil de programar como de distribuir.
Estoy esperando a la empresa que necesite algo así para montárselo e integrárselo en sus sistemas de gestión.

El problema que planteas exige que quien controla el servidor que mantiene la BD no esté controlando el que tiene los archivos. Eso no debería ser así y, si ocurre, opino que habrá que ir al superior de ambos departamentos para que resuelva el conflicto, que para eso está.