2010-02-09 44 views
14

Estoy planeando el desarrollo de una aplicación de galería de fotos para un cliente. Estoy desarrollando la aplicación en asp.net 3.5 y me gustaría desarrollarla para que pueda volver a usar la aplicación en múltiples plataformas usando varios front-ends. Básicamente, me pregunto cuáles son las desventajas y ventajas de almacenar imágenes en la base de datos como archivos binarios en lugar de simplemente almacenar los archivos en una carpeta de aplicaciones.¿Cuál es un mejor método para almacenar imágenes - carpeta o SQL Server como binario?

¡Cualquier consejo sería muy apreciado!

Gracias, Tristán

+3

Flickr usa la tienda de base de datos. Tal vez ellos saben una cosa o dos sobre esto. http://code.flickr.com/blog/2010/02/08/using-abusing-and-scaling-mysql-at-flickr/ – Yada

Respuesta

6

La desventaja de almacenar en formato binario es que se sopla el tamaño de base de datos a tamaños increíbles. Si tuviera que usar una edición expresa de SQL Server, que está limitada a 4 GB por base de datos, su galería de fotos "terminará" muy pronto.

La ventaja es que puede manipular fácilmente las restricciones de acceso por archivo y por usuario. Simplemente observe los derechos de los usuarios y decida si le devuelve la imagen o no.

+0

Este es un muy buen punto, había planeado usar SQL Server Express. – TGuimond

+0

No creo que haya ninguna ventaja de almacenar imágenes dentro de la base de datos. Los datos de restricciones de acceso se pueden ubicar fácilmente como un campo junto al campo de nombre de imagen. –

+5

Acepto que el sistema de archivos es mejor (y almacena la ruta), pero tenga en cuenta que poner las imágenes en la base de datos también ofrece consistencia transaccional. En SQL Server 2008 también puede investigar FILESTREAM, que es el mejor de ambos mundos: almacena las imágenes en la base de datos pero transmite al/del sistema de archivos, por lo que obtiene consistencia transaccional y otras ventajas de DB inherentes, sin explotar su base de datos tamaño. –

18

SQL Server 2008 admite FILESTREAM de almacenamiento.

Los archivos se almacenan en un volumen NTFS como archivos planos, pero están sujetos a control de transacciones y se puede acceder a través de los nombres de archivos especiales pasaron a Win32 API funciones (y por supuesto cualquier API construida sobre ella) con SQL Server comprobaciones adicionales de seguridad (como GRANT opciones, etc.).

4

El almacenamiento del sistema de archivos ofrecerá un rendimiento mucho mejor al guardar y servir imágenes, y es compatible con todas las plataformas. Si puedes vivir sin las ventajas de seguridad y transaccionales que obtienes del almacenamiento de db, entonces yo iría con el sistema de archivos.

+0

Saludos, eso es lo que voy a hacer. – TGuimond

1

Este debate ha estado ocurriendo en casi todas las comunidades de SQL Server durante años. hay buenos argumentos para ambas partes y definitivamente no hay solo una respuesta para todos los tamaños. Realmente depende de su situación individual y de muchos factores, como el número de usuarios, promedio. tamaño de archivo, frecuencia de actualización, relación de lectura/escritura, subsistema de disco yadayadayada ...

Pero como mencionas SQLExpress, probablemente el factor más importante es el límite máximo de tamaño de la base de datos y esta es una muy buena razón para ir al sistema de archivos enfoque. De todos modos, este documento de investigación podría ser interesante para usted: To BLOB or Not To BLOB: Large Object Storage in a Database or a Filesystem?

Este artículo solía encontrarse en el sitio de Microsoft Research aquí: http://research.microsoft.com/apps/pubs/default.aspx?id=64525, pero ese enlace no funciona para mí. SQL Server ha recorrido un largo camino desde entonces. Quassnoi ya mencionó a FILSTREAM, por ejemplo.

2

Tuvimos una gran aplicación de LOB que proporcionaba información de identificación de los cajeros de banco sobre el miembro que estaba frente a ellos. Nuestros datos textuales se almacenaron en SQL Server. Los datos de imagen se almacenaron en archivos. El campo de la base de datos simplemente tenía un nombre de archivo. Este enfoque funciona bien si está detrás del firewall. Leer y escribir archivos es fácil. El problema es la gestión de archivos. Debe asegurar el sistema de archivos para que las personas al azar no puedan ver el directorio. Además, las copias de seguridad son más complicadas con archivos de imagen sueltos. Tienes que hacer una copia de seguridad de la base de datos y los archivos de imagen. Los campos pueden hacer referencia a rutas que ya no existen. Por ejemplo, un técnico de TI decide mover la carpeta de imágenes y ahora todas las referencias en el archivo db están rotas. Si su aplicación necesita pasar información a través del firewall, le sugiero que almacene imágenes en SQL Server utilizando el mencionado almacenamiento FileStream.

Almacenar las imágenes en la base de datos nos habría ahorrado un poco de dolor. Solo tendríamos que hacer una copia de seguridad de la base de datos, sería más seguro, las referencias nunca se romperían y no hubiéramos tenido que saltar por los aros para obtener archivos de la red fuera del firewall.

+0

@Steve: es un 'FI_L_ESTREAM'. Solo pasa a través de un muro de archivos. – Quassnoi

+0

@Quassnoi, buena captura. Sin embargo, un tipo de FireStream sería genial. – Steve

+0

Tal vez si estuviera llamando a un servicio web a través de XFire http://xfire.codehaus.org/ –

Cuestiones relacionadas