Les dossiers MSDN

Nouveaux Types

Article par Pascal Belaud, Microsoft France

Pascal est en charge, depuis plus de 10 années, de la relation technique avec les développeurs chez Microsoft France. Vous pouvez le retrouver sur son blog à l’adresse : https://blogs.msdn.com/Pascal

Cet article a été originellement publié dans le magazine Programmez ! du mois d’octobre et novembre 2008 : www.programmez.com

 

Filestream

Les données que gèrent les entreprises au quotidien peuvent prendre diverses formes, les données structurées étant la forme la plus habituelle quand on est dans une base de données. Cependant, d’autres types de données, plus élaborées, doivent pouvoir y être stockées. Les fichiers binaires générés par des logiciels comme Word, Excel ou Powerpoint font partie de cette catégorie. Jusqu’à présent, pour stocker de telles données, nous avions la possibilité d’utiliser les types SQL Server prévus à cet effet comme image, varbinary(x). L’inconvénient de cette approche est que le stockage et la récupération des données implique nécessairement et intensivement le moteur de base de données. De plus, dans le cas où le type fichier stocké est un flux vidéo, il est impossible de démarrer, depuis l’application cliente, la lecture de ce flux vidéo tant que le moteur de base de données n’a pas entièrement renvoyé le contenu. On peut imaginer assez aisément les implications de ce mode de fonctionnement avec des fichiers de 2Go qui ne pourraient commencer à être lus qu’une fois que le moteur a extrait les 2 Go de contenu de ses fichiers de données.

Avec SQL Server 2008, une nouvelle fonctionnalité a été introduite pour résoudre ce problème : le type « FileStream ». Cette fonctionnalité va permettre au moteur de base de données d’utiliser une partition NTFS standard pour héberger les données de type « BLOB (Binary Large OBject) ». L’intérêt ici est que la copie (ainsi que la récupération) des données est totalement effectuée par le système d’exploitation et non pas le moteur de base de données. Ainsi, et à partir du moment où c’est l’OS qui prend en charge ce traitement, on peut donc bénéficier de la possibilité de « streamer » le contenu de ces fichiers, c'est-à-dire finalement la possibilité de commencer à lire le contenu du fichier dès que les premiers octets sont arrivés sur l’application cliente. Evidemment, la gestion de cette partition est totalement prise en charge par le moteur de base de données et aucun utilisateur n’a la possibilité d’accéder directement à son contenu. Il est donc obligatoire de passer par l’instance SQL Server 2008 pour toute opération de lecture et d’écriture, ce qui garantit donc une parfaite cohérence des données. De plus, la sauvegarde du contenu de cette partition est naturellement assurée via les mécanismes traditionnels de sauvegarde de bases de données sous SQL Server 2008. Enfin, la transaction est totalement préservée (elle est même obligatoire !) lorsqu’on manipule les données de type « FileStream ».

Pour mettre en œuvre cette fonctionnalité pour une instance SQL Server 2008, il faut tout d’abord la paramétrer, soit au niveau de l’outil d’administration de SQL Server 2008, le « Management Studio », soit via un script DDL.

exec sp_configure 'filestream_access_level', 2

 reconfigure

Une fois configurée au niveau de l’instance, pour pouvoir bénéficier de cette fonctionnalité, on se doit désormais de configurer les bases de données pour lesquelles nous souhaitons mettre en œuvre le « FileStream ».

ALTER DATABASE [bMSPress] ADD FILEGROUP [MonFileStreamGroup] CONTAINS FILESTREAM 

ALTER DATABASE [bMSPress] ADD FILE ( NAME = N'Photos', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL10.SQL2008\MSSQL\DATA\Photos' ) TO FILEGROUP [MonFileStreamGroup]

Enfin, lors de la déclaration d’une table, nous pouvons indiquer qu’une des colonnes va héberger des « BLOB » en utilisant le mot-clé « FileStream » de la manière suivante :

Create table dbo.Employé (

  Employé_ID uniqueidentifier not null rowguidcol unique,

  Employé_Nom nvarchar(50) not null,

  Employé_Prénom nvarchar(50) null,

  Employé_Photo varbinary(max) filestream null)

Voilà ! Désormais, les photos contenant dans la table des employés seront directement stockées dans le répertoire défini plus haut.

Spatial

Dans les applications de type GIS (Geographical Information System), on a généralement besoin de décrire des coordonnées géographiques, par exemple la position GPS (Global Positioning System) de tel ou tel magasin ou entrepôt. Mais au-delà de ça, on peut vouloir faire apparaître sur une carte la liste des magasins se trouvant à moins de 10 kms d’un point désigné. On peut également vouloir dessiner des formes de type polygone par exemple ou encore vouloir calculer les intersections entre ceux-ci. Bien-sûr, tout ceci se complique dès lors que l’on souhaite dessiner ces formes ou effectuer ces calculs sur des cartes planes et sur le globe terrestre (qui lui-même n’est pas tout à fait rond).

SQL Server 2008 arrive avec deux séries de type .NET permettant de gérer correctement le système géométrique (plan) et le système géodésique (globe). Ces types s’appellent « geometry » et « georgraphy ». Par exemple, dans le cade du système géodésique, si je souhaite voir une ligne droite reliant le Stade Vélodrome de Marseille (13) aux Ulis (91) (actuel siège de Microsoft France), il nous faut, une fois les coordonnées longitude/latitude de chacune des villes récupérées, initialiser le type « geography » comme suit :

declare @Marseille geography = geography::STPointFromText
      ('POINT(5.39219 43.27023)', 4326)

declare @Microsoft geography = geography::STPointFromText
      ('POINT(2.21533 48.69000)', 4326)

On peut également construire une nouvelle forme qui va se trouver être une ligne reliant ces deux points :

declare @Ligne geography = geography::STGeomFromText
      ('LINESTRING(5.39219 43.27023,2.21533 48.69000)', 4326)

Enfin, on peut directement visualiser la représentation cartographique de cette ligne depuis SQL Server 2008 :

Il est à noter que ces types « spatial » ne sont rien d’autre que des « User Defined Type » écrits en .NET (C#) et intégrés directement dans le moteur de base de données. Cette fonctionnalité, appelée en interne « SQLCLR », est apparue avec SQL Server 2005 et a été étendue avec SQL Server 2008 en supprimant notamment la limite de taille à 8 000 octets que nous avions pour le stockage des « UDT ».