Un petit papier pour présenter dans les grandes lignes une nouvelle fonctionnalité de SQL Server 2012 nommée FileTable et qui permet d’intégrer directement dans la base de données une arborescence de répertoire. Ca ressemble au FileStream déjà introduit en SQL Server 2008, mais il n’y a cette fois-ci plus besoin de passer par une API dédiée pour accéder aux données, la plupart des programmes d’édition de fichiers permettent d’agir directement sur ces données.
Du point de vue des étapes préparatoires, il convient tout d’abord de paramétrer le FileStream. Pour cela, il convient :

• De l’activer

• De fournir un chemin de stockage adéquat sur la base de données sur laquelle on souhaite l’utiliser

Une fois que ces paramètres sont en place, vous pouvez directement créer un nouveau type de table : une FileTable.

CREATE TABLE [dbo].[MaFileTable] AS FILETABLE ON [PRIMARY] FILESTREAM_ON [FG_FILESTREAM]
WITH
(
FILETABLE_DIRECTORY = N'Repertoire_MaFileTable', FILETABLE_COLLATE_FILENAME = French_CI_AS
)

A partir de là, un partage réseau est accessible, correspondant à la table qui vient d’être créée.

Et ce partage est désormais accessible de manière quasiment transparente. On peut être créer des dossiers et sous-dossiers, y positionner tout type de fichiers (Word, TXT, MP3, AVI…), qui pourront être accédés par les programmes habituels.

Et au final, comment cela est-ce stocké ? Et bien la table que nous venons de créer n’est rien d’autre qu’une table standard, avec une structure bien définie :

Chaque fichier ou répertoire est identifié par un identifiant. Derrière cela, nous avons principalement :

• le contenu du fichier (file_stream), sous forme de VARBINARY(MAX), pouvant donc contenir jusqu’à 2Go de données
• le nom du fichier ou du répertoire
• l’indicateur de chemin d’accès, et du dossier parent, sous forme d’expression binaire de type hierarchyId.
• les diverses propriétés du fichier (type, date-heure de création, propriétés Lecture Seule, Système, Archive, …)

Le fait d’avoir ce stockage sous forme de table permet notamment de ne plus avoir à gérer un système de sauvegarde séparé pour ces fameux fichiers. Tout est dans le backup standard de la base de données, avec tous les avantages que cela peut procurer (compression, sauvegardes différentielles, …).
De plus, étant donné que les différentes informations générales des fichiers sont disponibles, il est désormais possible de réaliser des scripts T-SQL qui viendront directement purger les données obsolètes, sans avoir à gérer cela sous forme de traitement MS-DOS ou PowerShell.
En résumé, il s’agit là d’une fonctionnalité à considérer plus que sérieusement…