¿Almacenar un archivo en una base de datos a diferencia del sistema de archivos?

En general, ¿qué tan malo es el rendimiento al almacenar un archivo en una base de datos (específicamente mssql) en lugar de hacerlo en el sistema de archivos? No puedo encontrar una razón fuera de la portabilidad de la aplicación que me gustaría almacenar mis archivos como varbinaries en SQL Server.

Eche un vistazo a esta respuesta:

Almacenar imágenes en DB – ¿Sí o No?

Básicamente, el impacto en espacio y rendimiento puede ser bastante grande, según 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 costosa y más difícil de escalar de una architecture web.

Hay algunos ejemplos opuestos (por ejemplo, Microsoft Sharepoint), pero generalmente, almacenar archivos en la base de datos no es una buena idea.

A menos que posiblemente escriba aplicaciones de escritorio y / o conozca aproximadamente cuántos usuarios tendrá, pero en algo tan aleatorio e inexperable 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 FILESTREAM que le ofrece 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 un archivo en un campo varchar. Su consulta puede devolver una secuencia de archivos .NET estándar, lo que hace que la integración sea mucho más simple.

Primeros pasos con FILESTREAM Storage

Yo diría que depende de tu situación. Por ejemplo, trabajo en el gobierno local, y tenemos muchas imágenes como mugshots, etc. No tenemos una gran cantidad de usuarios, pero necesitamos tener una buena seguridad y auditar los datos. La base de datos es una mejor solución para nosotros, ya que hace que esto sea más fácil y no vamos a tener problemas de escala.

¿Cuál es la pregunta aquí?

El moderno DBMS SQL2008 tiene una variedad de formas de tratar con BLOB que no solo se quedan pegados en una tabla. Hay ventajas y desventajas, por supuesto, y es posible que tenga que pensar un poco más.

Este es un documento interesante, por el difunto (?) Jim Gray

Para BLOB o No para 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 lo está. Por supuesto, hay algunas excepciones (por ejemplo, se supone que el muy publicitado sistema de archivos MS de próxima generación está construido 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 menos problemático para archivos pequeños.

Dejando a un lado el rendimiento, también depende de qué tan estrechamente acoplados estén los datos. Si el archivo contiene datos que están estrechamente relacionados con los campos de la base de datos, conceptualmente pertenece cerca de él y puede almacenarse en un blob. Si contiene información que podría relacionarse con múltiples registros o puede tener algún uso fuera del contexto de la base de datos, entonces pertenece al exterior. Por ejemplo, una imagen en una página web se obtiene en una solicitud separada de la página que se vincula con ella, por lo que puede pertenecer al exterior (dependiendo del diseño específico y las consideraciones de seguridad).

Nuestro compromiso, y no prometo que es el mejor, ha sido almacenar archivos XML pequeños en la base de datos pero imágenes y otros archivos fuera de él.

Tomamos la decisión de almacenar como varbinary para http://www.freshlogicstudios.com/Products/Folders/ a mitad de camino esperando problemas de rendimiento. Puedo decir que nos ha sorprendido gratamente lo bien que funcionó.

Estoy de acuerdo con @ZombieSheep. Solo una cosa más: en general, no creo que las bases de datos realmente deban ser portátiles porque se pierden todas las funciones que ofrece su proveedor de DBMS. Creo que migrar a otra base de datos sería lo último que uno consideraría. Solo mi $ .02

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 suficiente de un golpe aéreo para desanimarlo de hacerlo demasiado a menudo, especialmente si los archivos son bastante grande

No es vago ni nada, pero creo que el tipo de ‘archivo’ que va a almacenar es uno de los principales factores determinantes. Si esencialmente habla de un campo de texto grande que podría almacenarse como archivo, mi preferencia sería para el almacenamiento de db.