Hola.
Elaborando un poco sobre las dos opciones que propone Williams, para la opción 2 tienes ciertos beneficios en la parte de respaldo y restauración, porque tienes todo en un mismo lugar, cual es la BD. Adicionalmente, tu aplicación se beneficia porque
con un simple acceso a la BD, y no a la BD y al File System, obtiene la información que require. Por ultimo, garantizas temas como integridad de datos en cuanto a que la imagen está asociada a un registro particular en la BD. Sin embargo, esta opción no es
muy eficiente en términos de memoria y CPU y es por esto que, como bien indica Williams, tienes FileStream en SQL Server. Mayor información sobre FileStream en
esta entrada de la documentación en línea o en este buen libro electrónico en formato PDF de Redgate,
The Art of SQL Server Filestream.
Para la opción 1, debes tener en cuenta una estrategia para respaldo y restauración de tus archivos, complementaria a la de tu BD, ofrecer solo los accesos requeridos de acuerdo con los requerimientos de seguridad, es decir de autenticación y autorización
de tu aplicación y tener presente aspectos de disponibilidad del repositorio en donde estarán dichas imágenes. Algo que he visto es que algunas personas, para escenarios similares al tuyo, luego de que un usuario hace UPLOAD de las imágenes, cambian el nombre
para tener dentro de éste temas como fecha, usuario y un secuencial para también desde File System poder manipular los archivos.
En conclusion, hay mucho debate sobre este tema y recomendar algo en este momento puede ser contraproducente. En mi caso, he tenido buena experiencia con ambas aproximaciones e incluso diría que lo mejor es FileStream, lo cual incluso me ayudó mucho para
un escenario que involucró SharePoint Server 2010.
Si tienes tiempo, haz las pruebas con BD, BD+FileStream y archivos en el File System a ver que tal te va en términos de desempeño, seguridad y administración & operación. Quédate con la que mejor te funcione en general.
Saludos,
Guillermo Taylor F.
MVP SQL Server & IT Pro
Mi Blog
