En general, ¿qué impacto tiene el rendimiento en almacenar un archivo en una base de datos (específicamente en mssql) en lugar del sistema de archivos? No puedo encontrar una razón fuera de la portabilidad de la aplicación por la que me gustaría almacenar mis archivos como varbinaries en SQL Server.
Respuestas:
Eche un vistazo a esta respuesta:
Almacenamiento de imágenes en DB: ¿sí o no?
Esencialmente, el impacto en el espacio y el rendimiento puede ser bastante grande, dependiendo de la cantidad de usuarios. Además, tenga en cuenta que los servidores web son baratos y puede agregar más fácilmente para equilibrar la carga, mientras que la base de datos es la parte más cara y difícil de escalar de una arquitectura web.
Hay algunos ejemplos opuestos (por ejemplo, Microsoft Sharepoint), pero por lo general, almacenar archivos en la base de datos no es una buena idea.
A menos que posiblemente escriba aplicaciones de escritorio y / o sepa aproximadamente cuántos usuarios tendrá, pero en algo tan aleatorio e inesperado como un sitio web público, puede pagar un alto precio por almacenar archivos en la base de datos.
Si puede pasar a SQL Server 2008, puede aprovechar el soporte de FILESTREAM que le brinda lo mejor de ambos: los archivos se almacenan en el sistema de archivos, pero la integración de la base de datos es mucho mejor que simplemente almacenar una ruta de archivo en un campo varchar. Su consulta puede devolver un flujo de archivos .NET estándar, lo que simplifica mucho la integración.
Yo diría que depende de tu situación. Por ejemplo, trabajo en el gobierno local y tenemos muchas imágenes como fotos policiales, etc. No tenemos una gran cantidad de usuarios, pero debemos tener buena seguridad y auditoría de los datos. La base de datos es una mejor solución para nosotros, ya que facilita esto y no vamos a tener problemas de escala.
¿Cuál es la pregunta aquí?
Los DBMS SQL2008 modernos tienen una variedad de formas de lidiar con los BLOB que no se limitan a pegarlos en una tabla. Hay pros y contras, por supuesto, y es posible que deba pensarlo un poco más.
Este es un artículo interesante, del difunto (?) Jim Gray
BLOB o no BLOB: almacenamiento de objetos grandes en una base de datos o un sistema de archivos
En mi propia experiencia, siempre es mejor almacenar archivos como archivos. La razón es que el sistema de archivos está optimizado para el almacenamiento de archivos, mientras que una base de datos no. Por supuesto, hay algunas excepciones (por ejemplo, se supone que el tan anunciado sistema de archivos MS de próxima generación se construye sobre el servidor SQL), pero en general esa es mi regla.
Si bien el rendimiento es un problema, creo que los diseños modernos de bases de datos lo han hecho mucho menos problemático para archivos pequeños.
Dejando de lado el rendimiento, también depende de cuán estrechamente acoplados estén los datos. Si el archivo contiene datos que están estrechamente relacionados con los campos de la base de datos, entonces conceptualmente pertenece cerca de él y puede almacenarse en un blob. Si contiene información que podría relacionarse potencialmente con varios registros o puede tener algún uso fuera del contexto de la base de datos, entonces pertenece fuera. Por ejemplo, una imagen de una página web se obtiene en una solicitud separada de la página que la enlaza, por lo que puede pertenecer al exterior (según el diseño específico y las consideraciones de seguridad).
Nuestro compromiso, y no prometo que sea el mejor, ha sido almacenar archivos XML más pequeños en la base de datos, pero imágenes y otros archivos fuera de ella.
Tomamos la decisión de almacenar como varbinary para http://www.freshlogicstudios.com/Products/Folders/ a medias esperando problemas de rendimiento. Puedo decir que nos ha sorprendido gratamente lo bien que ha funcionado.
La sobrecarga de tener que analizar un blob (imagen) en una matriz de bytes y luego escribirlo en el disco con el nombre de archivo adecuado y luego leerlo es una sobrecarga suficiente para disuadirlo de hacer esto con demasiada frecuencia, especialmente si los archivos son bastante grande.