Barrapunto

En mi humilde opinión,

- Si la cantidad de ficheros a almacenar es muy grande y la capacidad no importa yo los pondría como campo en la BD. En el momento que están insertados tienes las mismas ventajas que el resto de información que almacenes en la DB, vease tratamiento de consultas, seguridad de acceso según usuarios, coherencia, etc. Por no comentar que lo tienes centralizado sin importante donde reside la información o si se te corrompe el sistema de ficheros (el SGDB te hace hasta el backup).

- En caso de que el número sea pequeño y el acceso lo quieras más primitivo aprovecha el sistema de ficheros.

Yo, personalmente, en cosas muy serias y con grandes cantidades de ficheros lo pondría con DB, sino no.

No debería, sobre todo si los campos LOB los almacenas en otro tablespace distinto, tal como se puede hacer en Oracle

Si la base de datos hace una indexación lógica no debería importar el tamaño de una tabla en la que guardas bitstreams (con su campo para indexación a parte, NUNCA uses para indexar un campo de gran tamaño (los bits del archivo) o que pueda repetirse) con otra en la que guardas ... los autores de esos ficheros por poner un ejemplo.

De hecho un campo de contenido ascii muy largo no deja de ser parecido a un fichero y si no recuerdo mal los artículos de la Wikipedia (y algunos no son ni mucho menos cortos) se guardan en un campo...Resumiendo, problemas de rendimiento no deberías tener si separas los datos y creas relaciones entre las diferentes tablas.

En PostgreSQL no he visto ninguna perdida de rendimiento al meter ficheros en una DB (miles de ficheros con un total de varios Gb).
Pero en Sybase me han dicho que si se nota que pierde rendimiento (esto no puedo asegurar).