Lluís Franco on Geeks.ms
  • Home

Editar documentos almacenados como array de bits en SQL Server [FileStream] (2/n)

  • By lfranco
  • Ago-18-2011
  • Sin categoría
  • 4 Comments.

En el anterior post de la serie os comentaba: “En los próximos posts veremos dónde se almacenan REALMENTE estos ficheros, cómo visualizarlos, y lo más importante de todo, cómo editarlos y guardarlos otra vez en la base de datos de forma transparente para el usuario.”

Dicho y hecho. Vamos a dar una ojeada al servidor SQL para ver dónde se almacenan estos ficheros. Recordar que al crear la base de datos debemos especificar un FILEGROUP explícitamente para el almacenamiento FILESTREAM:

CREATE DATABASE Archive 

ON

PRIMARY ( NAME = Arch1,

    FILENAME = 'c:dataarchdat1.mdf'),

FILEGROUP FileStreamGroup1 CONTAINS FILESTREAM( NAME = Arch3,

    FILENAME = 'c:datafilestream1')

LOG ON  ( NAME = Archlog1,

    FILENAME = 'c:dataarchlog1.ldf')

GO

El ejemplo anterior crea una estructura de carpetas y ficheros en la ubicación especificada del servidor SQL. Observar que no tiene porque ser la misma que los ficheros MDF y LDF, es más, para escenarios de alto rendimiento no os lo aconsejo precisamente.

 

Si damos una vistazo a esa estructura veremos que por defecto se crea un fichero filestream.hdr y una carpeta $FSLOG. El primero contiene los metadatos para el contenedor de los datos y el seguindo es el equivalente del log de transacciones de una base de datos. Pura magia!

fsfolders

En nuestro caso, aparece además una carpeta por cada entidad o tabla que contiene campos binarios con almacenamiento FILESTREAM. Como me he decicado a insertar varios documentos de pruebas en la tabla que creamos previamente (unos 1.500 para probar), la carpeta contiene una lista de ficheros similar a esto:

fsfiles

Estos ficheros no tienen extensión ni ningún tipo de vínculo con el documento original. Por eso es importante guardar en la tabla algunos de los metadatos del fichero original, ya que si no es imposible saber que tipo de documento es, ni como visualizarlo (ni mucho menos editarlo). También es importante resaltar que estos ficheros no pueden ser accedidos directamente a través de la red local. A todos los efectos los datos es como si estuviesen físicamente dentro de la tabla, en el fichero MDF.

Las grandes ventajas de este enfoque respecto a la alternativa ‘clásica’ de almacenar sólo la ruta de acceso a los documentos, y tener éstos en una ubicación de red son a mi juicio:

  • Atomicidad: Al fin tenemos un mecanismo que asegura que un registro y un fichero NTFS van a comportarse como una sola entidad, garantizando plenamente su integridad, olvidándonos de mecanismos de sincronización (con todo lo que conlleva).
  • Seguridad: La seguridad se gestiona desde SQL Server, con los usuarios y roles de SQL Server (independientemente de si usamos seguridad integrada o de SQL Server). Podemos olvidarnos de crear listas ACL separadas para controla los accesos a los ficheros NTFS.
  • Backups: Esto no se paga con dinero. Adios a tener que programar copias separadas de la base de datos y de los ficheros. Ahora al realizar un backup, SQL Server copiarà de forma automática la estructura de carpetas (y la restaurará, que es lo más importante).

Pero no todo son ventajas, os recomiendo dar una ojeada a la Tabla 1 de este artículo, que nos ofrece una comparativa muy detallada entre los 3 modelos (Filesystem, varbinary(max) y FILESTREAM).

Por ejemplo, una de las cosas que es muy sencillo hacer es la visualización y edición de los documentos, cuando éstos están almacenados en una ubicación de red  accesible por los usuarios de la aplicación. Si sabemos la ruta de acceso al fichero basta hacer un Process.Start y éste se abrirá con la aplicación asociada:

private void editDocument(string filename)

{

    Process.Start(filename);

}

Sin embargo utilizando almacenamiento FILESTREAM esto no es tan evidente… Pero eso lo dejo para el siguiente post.

Nos leemos pronto! 🙂

Comments

4 Responsesso far

  1. anonymous dice:
    18 agosto, 2011 a las 7:47 pm

    Que Buenos Post… Hace mucho que vengo mirando esto y no lo pude hacer andar…. no veo las horas de ver el post n/n :). Saludos

    Responder
  2. anonymous dice:
    19 agosto, 2011 a las 9:37 am

    gracias, siga asi, muy bueno, salu2grz

    Responder
  3. anonymous dice:
    19 agosto, 2011 a las 2:13 pm

    Hola, comento mi caso, pues tengo una aplicación .NET que gestiona muchos ficheros (PDF), y tenemos una base de datos con información de la «indexación» de esos documentos. Dichos documentos (ficheros PDF) se almacenan en disco. Nos plantemos usar FileStream ahora con Sql 2008 pero tenemos 400 GB de ficheros. ¿Será capaz sql server de tratar tanta información? y sobre todo temas de rendimiento preocupa; por ejemplo, hacer un backup de la bbdd y también los ficheros, tardaría mucho. Además, los ficheros están es una unidad de red diferente a la base de datos. En fin, estos posts son como agua de mayo y aclararán mucho. Esperamos el siguiente 😀 Gracias

    Responder
  4. lfranco dice:
    19 agosto, 2011 a las 2:24 pm

    Hola kikenet,
    Ya tienes el último post de la serie 🙂

    Dale un vistazo al enlace que publiqué en el post anterior:
    http://msdn.microsoft.com/en-us/library/cc949109(v=sql.100).aspx

    En tu caso particular, teniendo tanto volumen (400GB son muchos GB) creo que la mejor opción sería no usar FILESTREAM. No por volumen, ni por rendimientio, si no por lo que tu mismo has dicho: Un backup de 400GB se me antoja demasiado 🙁

    De todos modos, mira el artículo y decide tu mismo.

    Responder

Deja un comentario Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

← Previous Post Next Post →

Tags

async Back best practices

Entradas recientes

  • Video de mi charla en la #dotNetSpain2016
  • I’m back. Miss me?
  • Office365 actualizado a 2013 para nuevas suscripciones
  • Serializar listas genéricas en aplicaciones WinRT
  • [TPL] Problemas de concurrencia

Comentarios recientes

  • Darling Chavez en Tip: Mostrar objetos relacionados en DevExpress GridControl
  • Alexander en [TPL] Problemas de concurrencia
  • cristinakity en Funciones escalares en TSQL, JOINS, CROSS APPLY, y la madre que parió al topo.
  • cristinakity en Funciones escalares en TSQL, JOINS, CROSS APPLY, y la madre que parió al topo.
  • anonymous en HowTo: Crear una pantalla de inicio (splash screen)

Archivos

  • marzo 2016
  • marzo 2013
  • octubre 2012
  • septiembre 2012
  • agosto 2012
  • febrero 2012
  • diciembre 2011
  • noviembre 2011
  • octubre 2011
  • septiembre 2011
  • agosto 2011
  • junio 2011
  • mayo 2011
  • abril 2011
  • febrero 2011
  • enero 2011
  • diciembre 2010
  • noviembre 2010
  • octubre 2010
  • agosto 2010
  • julio 2010
  • marzo 2010
  • febrero 2010
  • enero 2010
  • diciembre 2009
  • noviembre 2009
  • octubre 2009
  • septiembre 2009
  • agosto 2009
  • julio 2009
  • junio 2009
  • mayo 2009
  • abril 2009
  • marzo 2009
  • febrero 2009
  • enero 2009
  • diciembre 2008
  • noviembre 2008
  • octubre 2008
  • septiembre 2008
  • agosto 2008
  • julio 2008
  • junio 2008
  • mayo 2008
  • abril 2008
  • marzo 2008
  • febrero 2008
  • enero 2008
  • diciembre 2007
  • noviembre 2007
  • octubre 2007
  • septiembre 2007
  • agosto 2007
  • abril 2007
  • febrero 2007
  • enero 2007

Categorías

  • .NET
  • C#
  • Channel9
  • Evento
  • Personal
  • Videos

Meta

  • Acceder
  • RSS de las entradas
  • RSS de los comentarios
  • WordPress.org
About This Site

A cras tincidunt, ut tellus et. Gravida scel ipsum sed iaculis, nunc non nam. Placerat sed phase llus, purus purus elit.

Archives Widget
  • January 2010
  • December 2009
  • November 2009
  • October 2009
Categories
  • Entertainment
  • Technology
  • Sports & Recreation
  • Jobs & Lifestyle
Search
  • facebook
  • twitter
  • rss

Powered by WordPress  |  Business Directory by InkThemes.

This site uses cookies: Find out more.