Barrapunto

Si lo guardas en disco duro puede pasarte dos cosas:

1 - Si utilizas una herramienta de Backup para Oracle es dificil incluir la ruta donde dejes los ficheros.

2 - En caso de corrupción de la partición no tienes las herramientas de recuperación que puede tener un gestor de Base de Datos como Oracle.

Si guardas la información en la BD como un campo LOB puedes separarlos en otro tablespace diferente para evitar problemas en el tablespace de datos. Los ficheros también se pueden enviar directamente sin necesidad de realizar un ftp o exportar directorios por NFS o SMB. En el cliente puedes recuperar el fichero mediante una SELECT a dicho campo utilizando las estructuras correspondientes el PL/SQL o mediante ProC o su equivalente en Java.

Creo que Oracle también se encarga de realizar la compresión de dichos campo LOB.

¿Como lo hace los sistemas documentales existentes, tal como Documentum? Guardan los ficheros en campos LOB de la BD Oracle o similar.

Documentum por defecto lo guarda en filesystem, y desde luego es mucho más eficiente que en campos BLOB o similares, por muy bien tuneado que este el Oracle.
Respecto a lo que se comenta de Backup, simplemente hay que hacer uno del SGBD y otro del Filesystem.

Consulta la documentación de MySQL, tal como yo lo hice en su dia con Oracle.

No obstante, si te permite utilizar campos LOB, debería tener las mismas posibilidades, aunque según lo que he visto, en la sentencia CREATE TABLE no se puede indicar que un campo se guarde en un fichero de datos distintos, tal como se puede hacer en Oracle. Esto se podría solucionar creando dos tablas (una para los datos y la otra para los campos LOB con un código único compartido) y una vista de actualización, que permita crear, borrar y consultar los datos tal como si fuera una sola tabla.

No tengo conocimiento de si en otros gestores de Base de datos que no sean Oracle pueden realizar esto. Para eso esta la documentación y nuestra inteligencia.