Résumé : Ce livre blanc décrit la fonctionnalité filestream de sql server 2008, qui permet le stockage et l'accès aux données blob en associant sql server 2008 et le système de fichiers ntfs.

Options de stockage d'objets BLOB

• 
  Performances : la façon dont les données vont être utilisées est un facteur essentiel. Si l'accès en continu est nécessaire, le stockage des données dans une base de données SQL Server peut être plus lent que le stockage externe dans un emplacement tel que le système de fichiers NTFS. Avec le stockage du système de fichiers, les données sont lues dans le fichier et transmises
  à l'application cliente (directement ou avec mise en mémoire tampon supplémentaire). Lorsque les données blob sont stockées dans une base de données SQL Server, elles doivent d'abord être lues dans la mémoire de SQL Server (le pool de mémoires tampons), puis être retransmises via une connexion cliente à l'application cliente. Cela signifie non seulement que les données passent par une étape de traitement supplémentaire, mais également que la mémoire de SQL Server est inutilement « polluée » par des données BLOB, ce qui peut entraîner d'autres problèmes de performances pour les opérations SQL Server.
  
• 
  Sécurité : les données sensibles dont l'accès doit être étroitement géré peuvent être stockées dans une base de données et la sécurité peut être contrôlée en utilisant les contrôles d'accès SQL Server habituels. Si les mêmes données sont stockées dans le système de fichiers, différentes méthodes de sécurité, telles que les listes de contrôle d'accès (ACL), doivent être implémentées.
  
• 
  Taille des données : selon l'étude mentionnée plus loin dans ce livre blanc, les objets blob d'une taille inférieure à 256 kilo-octets (Ko) (tels que des icônes de widget) sont mieux adaptés au stockage dans une base de données, et les objets blob d'une taille supérieure à 1 Mo sont plus adaptés au stockage en dehors de la base de données. Pour ceux dont la taille est comprise entre 256 Ko et 1 Mo, la solution de stockage la plus efficace dépend du rapport lecture/écriture des données et de la fréquence de « remplacement ». Le stockage des données BLOB uniquement dans la base de données (par exemple, en utilisant le type de données varbinary (max)) est limité à 2 gigaoctets (Go) par BLOB.
  
• 
  Accès du client : le protocole utilisé par le client pour accéder aux données SQL Server, tel qu'ODBC, peut ne pas être adapté aux applications telles que les fichiers volumineux de flux vidéo. Cela peut nécessiter le stockage des données dans le système de fichiers.
  
• 
  Sémantique transactionnelle : si les données BLOB possèdent des données structurées associées qui sont stockées dans la base de données, les modifications apportées aux données BLOB doivent respecter la sémantique transactionnelle de façon à ce que les deux ensembles de données restent synchronisés. Par exemple, si une transaction crée des données BLOB et une ligne dans une table de base de données, puis annule l'opération, la création des données BLOB doit être annulée, ainsi que la création de la ligne dans la table. Cela peut s'avérer très complexe si les données BLOB sont stockées dans le système de fichiers sans lien vers la base de données.
  
• 
  Fragmentation des données : les mises à jour et remplacements fréquents entraînent le déplacement des objets blob, dans les fichiers de base de données SQL Server ou dans le système de fichiers, en fonction de l'emplacement de stockage des données. Dans ce cas, si les objets blob sont volumineux, ils peuvent être fragmentés. (c.-à-d., ne pas être stockés dans une partie contiguë du disque). Cette fragmentation est plus aisément traitée à l'aide du système de fichiers qu'à l'aide de SQL Server.
  
• 
  Simplicité de gestion : une solution utilisant différentes technologies qui ne sont pas intégrées sera plus complexe et coûteuse à gérer qu'une solution intégrée.
  
• 
  Coût : le coût de la solution de stockage varie selon la technologie utilisée.