SQL Server 2008

Nouveaux types de données

Kelly Wilson

Vue d'ensemble:

• Nouveaux types de données de date et d'heure
• Représentation de la position dans une hiérarchie
• Deux modèles pour la manipulation des données spatiales

Dans notre économie mondialisée, les activités commerciales nécessitent de plus en plus que les entreprises utilisent de nouveaux types de données, d'applications et de calculs complexes. Les sept nouveaux types de données intégrés à SQL Server 2008

fournissent les moyens nécessaires pour travailler avec des données plus complexes et simplifier leur gestion.

Date et time

Avec l'ancien type de donnée datetime, les utilisateurs de SQL Server® n'avaient pas la possibilité de travailler avec les informations de date et d'heure séparément. Quatre des nouveaux types de données (date, time, datetime2 et datetimeoffset) y remédient, simplifiant ainsi la manipulation des données de date et d'heure et permettant l'utilisation de plages de dates, une précision de l'ordre de la fraction de seconde et la prise en charge des fuseaux horaires. Les nouvelles applications de base de données devraient utiliser ces nouveaux types de données au lieu de l'ancien datetime. Examinons de plus près ces nouvelles versions.

Le type de données date enregistre une date sans composant d'heure. Sa plage de valeurs s'étend du 1er janvier 1000 au 31 décembre 9999 (0001-01-01 à 9999-12-31). Chaque variable de date nécessite 3 octets de stockage et possède une précision de 10 chiffres. La précision du type date se limite à un jour.

Examinons la figure 1, qui montre comment créer et initialiser les variables Date dans les scripts T-SQL. La variable @myDate1 est initialisée par une chaîne au format « MM/JJ/AAAA ». La variable @myDate2 n'est pas initialisée. Elle aura la valeur NULL. La variable @myDate3 est initialisée avec la date de l'ordinateur local. La valeur des variables peut être modifiée à tout moment avec les instructions SELECT et SET, comme le montre l'exemple modifiant la valeur de @myDate2. Des colonnes date peuvent également être créées dans les tables. La figure 2 montre comment créer une table avec trois colonnes date.

Figure 2 Créer une table avec trois colonnes date

USE TempDB
GO

CREATE TABLE myTable
(
    myDate1 date,myDate2 date,myDate3 date
)
GO

INSERT INTO myTable
VALUES('01/22/2005',
       '2007-05-08 12:35:29.1234567 +12:15',
       GetDate())

SELECT * FROM myTable

--Results
--myDate1    myDate2    myDate3
------------ ---------- ----------
--2005-01-22 2007-05-08 2007-11-20

Figure 1 Créer et initialiser les variables date dans les scripts T-SQL

DECLARE @myDate1 date = '01/22/2005'
DECLARE @myDate2 date
DECLARE @myDate3 date = GetDate()

SELECT @myDate2 = '2007-05-08 12:35:29.1234567 +12:15'

SELECT @myDate1 AS '@myDate1',
       @myDate2 AS '@myDate2',
       @myDate3 AS '@myDate3'

--Results
--@myDate1   @myDate2   @myDate3
------------ ---------- ----------
--2005-01-22 2007-05-08 2007-11-20

Le type de données time enregistre l'heure du jour sans composant de date. Il est basé sur une horloge de 24 heures et sa plage prise en charge est donc 00:00:00,0000000 à 23:59:59,9999999 (heures, minutes, secondes et fractions de secondes). Vous pouvez spécifier la précision fractionnaire de la seconde lorsque le type de données est créé. La précision par défaut est 7 chiffres, ce qui correspond à 100 ns. La précision affecte l'espace de stockage nécessaire, qui peut s'étendre de 3 octets jusqu'à 2 chiffres et 4 octets pour 3 à 4 chiffres à 5 octets pour 5 à 7 chiffres.

Le script T-SQL de la figure 3 illustre la façon dont la précision de la variable est affectée par les conversions implicites d'une valeur d'initialisation de chaîne. Le code T-SQL crée tout d'abord et initialise huit variables time distinctes de valeur identique. La précision fractionnaire de chaque variable correspond à son nom. Par exemple, @myTime3 possède une précision fractionnaire de trois décimales. Les résultats montrent que la précision de chaque donnée de type time est équivalente à la précision fractionnaire avec laquelle elle a été déclarée. Les décimales qui ne rentrent pas dans la plage sont tronquées.

Figure 3 Afficher la précision de la variable de type de données time

DECLARE @myTime  time = '01:01:01.1234567 +01:01'
DECLARE @myTime1 time(1) = '01:01:01.1234567 +01:01'
DECLARE @myTime2 time(2) = '01:01:01.1234567 +01:01'
DECLARE @myTime3 time(3) = '01:01:01.1234567 +01:01'
DECLARE @myTime4 time(4) = '01:01:01.1234567 +01:01'
DECLARE @myTime5 time(5) = '01:01:01.1234567 +01:01'
DECLARE @myTime6 time(6) = '01:01:01.1234567 +01:01'
DECLARE @myTime7 time(7) = '01:01:01.1234567 +01:01'

SELECT @myTime  AS '@myTime',
       @myTime1 AS '@myTime1',
       @myTime2 AS '@myTime2',
       @myTime3 AS '@myTime3',
       @myTime4 AS '@myTime4',
       @myTime5 AS '@myTime5',
       @myTime6 AS '@myTime6',
       @myTime7 AS '@myTime7'

--Results
--@myTime          @myTime1   @myTime2    @myTime3     @myTime4      
------------------ ---------- ----------- ------------ -------------
--01:01:01.1234567 01:01:01.1 01:01:01.12 01:01:01.123 01:01:01.1235
--
--@myTime5       @myTime6        @myTime7
---------------- --------------- ----------------
--01:01:01.12346 01:01:01.123457 01:01:01.1234567

DROP TABLE myTable

Un type de données time peut être créé en tant que colonne d'une table. Le script T-SQL DROP TABLE myTable de la figure 4 crée une table nommée myTable1 et ajoute trois colonnes time à la table. Un enregistrement est alors inséré dans la table et le contenu de la table est affiché avec une instruction SELECT.

Figure 4 Créer myTable1

USE TempDB
GO

CREATE TABLE myTable1
(
    myTime1 time(1),
    myTime2 time(2),
    myTime3 time(3)
)
GO

INSERT INTO myTable1
VALUES('01:30:01.1234567',
       '02:34:01.1234567',
       '03:01:59.1234567')

SELECT * from myTable1

--Results
--myTime1    myTime2     myTime3
------------ ----------- ------------
--01:30:01.1000000 02:34:15.1200000 03:01:59.1230000

DROP TABLE myTable1

Datetimeoffset et Datetime2

Le type de données datetimeoffset fournit la prise en charge des fuseaux horaires. Le type de données time ne contient pas de fuseau horaire et fonctionne uniquement à l'heure locale. Toutefois, dans notre économie mondialisée, il est souvent nécessaire de connaître la relation entre une heure d'une région du monde et l'heure d'une autre région. Le décalage de fuseau horaire est indiqué comme + ou - hh:mm.

Ce code crée une variable datetimeoffset et l'initialise avec la valeur d'heure 8h52, heure du Pacifique :

DECLARE @date DATETIMEOFFSET = '2007-11-26T08:52:00.1234567-08:00'
PRINT @date
--Results
--2007-11-26 08:52:00.1234567 -08:00

La chaîne qui initialise la variable datetimeoffset (@date dans le script) est spécialement mise en forme, ordonnée de l'élément le plus significatif au moins significatif. Une lettre T majuscule unique sépare les éléments de date et d'heure. Un signe moins sépare les éléments d'heure du fuseau horaire. Il n'y a pas d'espace entre le signe moins et les éléments d'heure ou de fuseau horaire. Ce format est l'un des deux formats ISO 8601 pris en charge par le type de données datetimeoffset. (ISO 8601 est une norme internationale pour la représentation des valeurs de date et d'heure)

La précision du composant d'heure est spécifiée comme pour le type de données d'heure, et elle utilise également sept chiffres, sauf spécification différente. La plage prise en charge est la même.

Le type de données datetime2 est une extension du type datetime original. Il prend en charge une plus grande plage de dates et une plus grande précision de fractions de secondes, et vous permet de spécifier la précision. La plage de dates du type datetime2 s'étend du 1er janvier 0001 au 31 décembre 9999, par comparaison à la plage 1er janvier 1753 au 31 décembre 9999 du type datetime original. Comme avec le type time, sept décimales de précision sont fournies pour les secondes. Le type datetime original compte trois chiffres pour la précision et une plage horaire s'étendant de 00:00:00 à 23:59:59,999. Voici comment créer une variable datetime2 et l'initialiser avec la date et l'heure locales du serveur :

DECLARE @datetime2 DATETIME2 = GetDate();
PRINT @datetime2

--Results
--2007-11-26 09:39:04.1370000

Je vais maintenant examiner le nouveau type de données hierarchyid. Ce type de données fonctionne avec la relation entre les éléments de données d'une table, plutôt qu'avec des données de date ou d'heure spécifiques.

Type de données hierarchyid

Le type de données hierarchyid vous permet de construire des relations entre les éléments de données d'une table, et en particulier de représenter une position dans une hiérarchie. Pour explorer ce type de données, commençons par créer la base de données MyCompany et la remplir avec des données d'employé, à l'aide du script de la figure 5.

Figure 5 Créer et remplir la base de données MyCompany

USE MASTER
GO

CREATE DATABASE MyCompany
GO
USE MyCompany
GO

--Create a table called employee that will store
--the data for the employees for MyCompany.
    
CREATE TABLE employee
(
    EmployeeID int NOT NULL,
    EmpName    varchar(20) NOT NULL,
    Title      varchar(20) NULL,
    Salary     decimal(18, 2) NOT NULL,
    hireDate   datetimeoffset(0) NOT NULL,
)
GO

--These statements will insert the data for the employees of MyCompany.

INSERT INTO employee
VALUES(6,   'David',  'CEO', 35900.00, '2000-05-23T08:30:00-08:00')

INSERT INTO employee
VALUES(46,  'Sariya', 'Specialist', 14000.00, '2002-05-23T09:00:00-08:00')

INSERT INTO employee
VALUES(271, 'John',   'Specialist', 14000.00, '2002-05-23T09:00:00-08:00')

INSERT INTO employee
VALUES(119, 'Jill',   'Specialist', 14000.00, '2007-05-23T09:00:00-08:00')

INSERT INTO employee
VALUES(269, 'Wanida', 'Assistant', 8000.00, '2003-05-23T09:00:00-08:00')

INSERT INTO employee
VALUES(272, 'Mary',   'Assistant', 8000.00, '2004-05-23T09:00:00-08:00')
GO
--Results
--EmployeeID  EmpName Title      Salary   hireDate
------------- ------- ---------- -------- --------------------------
--6           David   CEO        35900.00 2000-05-23 08:30:00 -08:00
--46          Sariya  Specialist 14000.00 2002-05-23 09:00:00 -08:00
--271         John    Specialist 14000.00 2002-05-23 09:00:00 -08:00
--119         Jill    Specialist 14000.00 2007-05-23 09:00:00 -08:00
--269         Wanida  Assistant  8000.00  2003-05-23 09:00:00 -08:00
--272         Mary    Assistant  8000.00  2004-05-23 09:00:00 -08:00

La figure 6 illustre la base de données simple résultante, composée d'une seule table d'employés. Cette table d'employés de la base de données MyCompany ne possède pas de structure imposée. Ceci est normal pour une base de données relationnelle, car la structure est imposée dynamiquement par une application via son code de requête et de traitement.

Figure 6** Table d'employés MyCompany **

Les données de l'entreprise, cependant, ont généralement un type de structure inhérente. Par exemple, chaque entreprise possède une structure hiérarchique, comme celle illustrée pour MyCompany à la figure 7. Tous les employés de MyCompany sont des subordonnés de David, le PDG (CEO). Certains employés sont ses subordonnés directs, comme c'est le cas pour Jill. Les autres, tels que Marie, sont séparés par un intermédiaire. En termes de programmation, la structure hiérarchique de MyCompany porte le nom d'arborescence, car c'est la forme physique qu'elle possède. David, au sommet, n'est subordonné de personne. Il est le parent ou ancêtre. Les employés subordonnés de David sont situés au-dessous. Ces nœuds portent le nom d'enfants ou descendants. David peut posséder autant de descendants que nécessaire pour représenter ses subordonnés directs.

Figure 7** Structure organisationnelle de MyCompany **(Cliquer sur l'image pour l'agrandir)

Le script de la figure 8 reconstruit la base de données MyCompany à l'aide du type de données hierarchyid, construisant ainsi une relation qui correspond à la structure hiérarchique de MyCompany. L'instruction ALTER TABLE est utilisée pour ajouter tout d'abord une colonne de type hierarchyid. Le nœud de David est alors inséré avec la méthode GetRoot de hierarchyid. Les subordonnés directs de David sont alors ajoutés à l'arborescence avec la méthode GetDescendant.

Figure 8 Reconstruire la base de données avec hierarchyid

DELETE employee
GO
ALTER TABLE employee ADD OrgNode hierarchyid NOT NULL
GO

DECLARE @child hierarchyid,
@Manager hierarchyid = hierarchyid::GetRoot()

--The first step is to add the node at the top of the
--tree. Since David is the CEO his node will be the
--root node.

INSERT INTO employee
VALUES(6,   'David',  'CEO', 35900.00,
       '2000-05-23T08:30:00-08:00', @Manager)

--The next step is to insert the records for
--the employees that report directly to David.

SELECT @child = @Manager.GetDescendant(NULL, NULL)

INSERT INTO employee
VALUES(46,  'Sariya', 'Specialist', 14000.00,
       '2002-05-23T09:00:00-08:00', @child)

SELECT @child = @Manager.GetDescendant(@child, NULL)
INSERT INTO employee
VALUES(271, ‚John',   ‚Specialist', 14000.00,
       '2002-05-23T09:00:00-08:00', @child)

SELECT @child = @Manager.GetDescendant(@child, NULL)
INSERT INTO employee
VALUES(119, ‚Jill',   ‚Specialist', 14000.00,
       ‚2007-05-23T09:00:00-08:00', @child)

--We can now insert the employee that reports to
--Sariya.
SELECT @manager = OrgNode.GetDescendant(NULL, NULL)
FROM employee WHERE EmployeeID = 46

INSERT INTO employee
VALUES(269, ‚Wanida', ‚Assistant', 8000.00,
       ‚2003-05-23T09:00:00-08:00', @manager)

--Next insert the employee that report to John.
SELECT @manager = OrgNode.GetDescendant(NULL, NULL)
FROM employee WHERE EmployeeID = 271

INSERT INTO employee
VALUES(272, ‚Mary',   ‚Assistant', 8000.00,
       ‚2004-05-23T09:00:00-08:00', @manager)
GO

Une fois les enregistrements de base de données ajoutés et la hiérarchie construite, le contenu de la table des employés peut être affiché avec une requête telle que celle-ci :

SELECT EmpName, Title, Salary, OrgNode.ToString() AS OrgNode
FROM employee ORDER BY OrgNode
GO
--Results
--EmpName  Title      Salary    OrgNode
---------- ---------- --------- -------
--David    CEO        35900.00  /
--Sariya   Specialist 14000.00  /1/
--Wanida   Assistant  8000.00   /1/1/
--John     Specialist 14000.00  /2/
--Mary     Assistant  8000.00   /2/1/
--Jill     Specialist 14000.00  /3/

OrgNode est la colonne hierarchyid. Chaque caractère barre oblique du résultat indique un nœud dans l'arborescence de la hiérarchie. David est à la racine, qui est indiquée par une barre oblique unique. Sariya, John et Jill sont des subordonnés directs de David et possèdent deux barres obliques, indiquant qu'ils représentent le deuxième nœud de la hiérarchie. Les numéros 1, 2 et 3 affichent l'ordre de chaque nœud enfant. Ce système est très souple. Les nœuds enfants peuvent être supprimés, insérés ou ajoutés selon les besoins. Si nous avions ajouté un employé entre John et Jill, par exemple, cet employé serait répertorié dans le jeu de résultats comme suit : /2.1/.

Pour répondre par exemple à la question « Qui est sous l'autorité de Sariya », vous pouvez créer une requête telle que celle du code T-SQL suivant :

DECLARE @Sariya hierarchyid

SELECT @Sariya = OrgNode
FROM employee WHERE EmployeeID = 46

SELECT EmpName, Title, Salary, OrgNode.ToString() AS 'OrgNode'
FROM employee
WHERE OrgNode.GetAncestor(1) = @Sariya
GO
--Results
--EmpName Title     Salary  OrgNode
--------- --------- ------- -------
--Wanida  Assistant 8000.00 /1/1/

La requête utilise la méthode GetAncestor de hierarchyid, qui renvoie le parent du nœud hierarchyid actuel. Dans le code précédent, la variable @Sariya est définie sur le nœud hiérarchique pour Sariya. C'est parce que Sariya est l'ancêtre direct de tout employé qui est sous son autorité. Par conséquent, l'écriture d'une requête qui renvoie les employés qui sont sous l'autorité directe de Sariya consiste à récupérer le nœud de Sariya depuis l'arborescence et à sélectionner ensuite tous les employés dont le nœud ancêtre est le nœud de Sariya.

Les colonnes hierarchyid ont tendance à être très compactes car le nombre de bits nécessaires pour représenter un nœud dans une arborescence dépend du nombre moyen d'enfants pour le nœud (habituellement appelé sortance du nœud). Par exemple, un nouveau nœud dans une hiérarchie organisationnelle de 100 000 employés, avec une sortance moyenne de six niveaux, nécessiterait à peu près cinq octets de stockage.

Le type de données hierarchyid fournit plusieurs méthodes facilitant l'utilisation des données hiérarchiques. Un récapitulatif de ces méthodes est présenté à la figure 9. Des informations détaillées sur toutes les méthodes sont disponibles dans la documentation en ligne de SQL Server (msdn2.microsoft.com/ms130214).

Figure 9 Méthodes fournies par le type de données hierarchyid

Types de données spatiales

Les données spatiales sont des données qui identifient des formes et des emplacements géographiques, principalement sur terre. Ceux-ci peuvent être des points d'intérêt, des routes ou même l'emplacement d'entreprises. SQL Server 2008 fournit les types de données Geography et Geometry nécessaires à l'utilisation de ce type de données.

Le type de données Geography utilise des informations à base d'un modèle de terre ronde. Le modèle de terre ronde prend en compte la surface courbée de la terre dans ses calculs. Les informations de position sont données en longitude et latitude. Ce modèle est particulièrement adapté aux applications telles que l'expédition transocéanique, la planification militaire et les applications courte portée dont la surface de la terre constitue la référence. Ceci est le modèle à utiliser si vos données sont stockées sous forme de latitudes et longitudes.

Le type de données Geometry fonctionne avec le modèle de terre plate ou modèle planaire. Dans ce modèle, la terre est considérée comme une projection plate commençant à un point connu. Le modèle de terre plate ne prend pas en compte la courbure de la terre, et est donc principalement utilisé pour décrire les distances courtes, par exemple dans une application de base de données qui cartographie l'intérieur d'un bâtiment.

Les types Geography et Geometry sont construits à partir d'objets vectoriels, spécifiés au format WKT (Well-Known Text) ou WKB (Well-Known Binary). Il s'agit de formats de transport pour les données spatiales décrites par la spécification Simple Feature for SQL de l'Open Geospatial Consortium (OGC). La figure 10 répertorie les sept types d'objets vectoriels pris en charge par SQL Server 2008.

Figure 10 Objets vectoriels pris en charge par SQL Server 2008

Pour construire un type Geography avec un ou plusieurs objets vectoriels, vous devez d'abord déclarer le type Geography dans votre script T-SQL, comme indiqué sur la figure 11. Appelez ensuite une des méthodes listées à la figure 12 et transmettez la chaîne de caractères de votre objet vectoriel et l'ID de référence spatiale (SRID). Le SRID est le système d'identification de référence spatiale, défini par l'European Petroleum Survey Group. Il fait partie d'un ensemble de normes développées pour la cartographie, l'arpentage et le stockage de données géodésiques. Chaque SRID identifie un type spécifique d'ellipsoïde à utiliser dans les calculs géographiques. Ceci est nécessaire car la terre n'est pas une sphère parfaite. SQL Server 2008 peut uniquement exécuter des calculs sur des SRID identiques.

Figure 12 Objets constructeurs pour Geography et Geometry

Figure 11 Créer des points, des lignes et des polygones Geometry

DECLARE @geo1 geometry
SELECT @geo1 = geometry::STGeomFromText('POINT (3 4)', 0)
PRINT @geo1.ToString()

DECLARE @geo2 geometry
SELECT @geo2 = geometry::Parse('POINT(3 4 7 2.5)')
PRINT @geo2.STX;
PRINT @geo2.STY;
PRINT @geo2.Z;
PRINT @geo2.M;

DECLARE @geo3 geography;
SELECT @geo3 = geography::STGeomFromText(
    'LINESTRING(47.656 -122.360, 47.656 -122.343)', 4326);
SELECT @geo3.ToString();

--Results
--POINT (3 4)
--3
--4
--7
--2.5

DECLARE @gx geometry; 
SET @gx = geometry::STPolyFromText(
    'POLYGON ((5 5, 10 5, 10 10, 5 5))', 0);
PRINT @gx.ToString();
--Results
--POLYGON ((5 5, 10 5, 10 10, 5 5))

Différences entre Geography et Geometry

Les types de données Geography et Geometry sont conçus pour être utilisés avec des types de données différents et présentent par conséquent certaines différences essentielles dont vous devez être conscient. Avec le type de données Geometry, les distances et les zones sont indiquées dans la même unité de mesure que les coordonnées des instances. Par exemple, la distance entre les points (0,0) et (6,8) sera toujours 10 unités. Ceci n'est pas le cas avec le type Geography, qui utilise des coordonnées ellipsoïdales exprimées en degrés de latitude et de longitude.

Le type de données Geometry renvoie des résultats incohérents lorsque les coordonnées sont exprimées en tant que couples latitude-longitude. Le code T-SQL suivant calcule la distance entre les POINTS (90 0) et (90 180). Ces deux points font référence au pôle Nord et la distance entre ceux-ci doit être 0. Dans le cas de Geometry, la distance calculée est 180.

DECLARE @g1 GEOMETRY, @g2 GEOMETRY, @g3 GEOGRAPHY, @g4 GEOGRAPHY
SELECT @g1 = GEOMETRY::STGeomFromText('POINT (90 0)', 0)
SELECT @g2 = GEOMETRY::STGeomFromText('POINT (90 180)', 0)

SELECT @g3 = GEOGRAPHY::STGeomFromText('POINT (90 0)', 4326)
SELECT @g4 = GEOGRAPHY::STGeomFromText('POINT (90 180)', 4326)
SELECT @g2.STDistance(@g1) AS 'GEOMETRY',
       @g4.STDistance(@g3) AS 'GEOGRAPHY';

--Results
--GEOMETRY               GEOGRAPHY
------------------------ ----------------------
--180                    0

L'orientation des données spatiales est également différente pour les deux types de données. Dans le système planaire utilisé par le type de données Geometry, l'orientation d'un polygone n'est pas un facteur important. Par exemple, un polygone avec les coordonnées ((0, 0), (10, 0), (0, 20), (0, 0)) est considéré identique au polygone ((0, 0), (0, 20), (10, 0), (0, 0)). Mais dans le modèle de données utilisé par le type de données Geography, un polygone est incertain sans orientation spécifiée. Prenez par exemple un anneau autour de l'équateur. Le polygone décrit par cet anneau fait-il référence à l'hémisphère septentrional ou méridional ? L'idée ici est que, lors de la manipulation de données de type Geography, l'orientation et l'emplacement doivent être décrits avec précision.

Il existe également certaines restrictions placées sur le type de données Geography par SQL Server 2008. Par exemple, chaque instance de Geography doit trouver place dans un seul hémisphère. Les grands objets spatiaux ne sont pas autorisés et provoqueront la levée d'une exception ArgumentException. Les types de données Geography nécessitant deux entrées renverront NULL si les résultats des méthodes ne trouvent pas place dans un seul hémisphère.

SQL Server fournit plusieurs méthodes permettant d'effectuer des opérations sur les instances de Geography et Geometry. La figure 13 illustre certains exemples utilisant les méthodes fournies par SQL Server 2008 pour la manipulation des données spatiales. En raison de contraintes d'espace, je ne peux pas entrer plus en détail sur ce sujet, mais vous trouverez une description complète dans la documentation en ligne de SQL Server.

Figure 13 Utilisation des données spatiales

DECLARE @gm geometry;
DECLARE @gg geography;
DECLARE @h geography;

SET @gm = geometry::STGeomFromText('POLYGON((0 0, 13 0, 3 3, 0 13, 0 0),(2 2, 2 1, 1 1, 1 2, 2 2))', 0);
SELECT @gm.STArea();

--Results
--38

SET @gg = geography::STGeomFromText('LINESTRING(0 0, 5 5)', 4326);
--Calculate the distance to a point slightly offset from the LINESTRING.
SET @h = geography::STGeomFromText('POINT(4 4)', 4326);
SELECT @gg.STDistance(@h);

--Results
-- 430.182777043046

--Calculate the distance to a point on the LINESTRING.
SET @h = geography::STGeomFromText('POINT(5 5)', 4326);
SELECT @gg.STDistance(@h);

--Results
-- 0

DECLARE @temp table ([name] varchar(10), [geom] geography);

INSERT INTO @temp values ('Point', geography::STGeomFromText('POINT(
5 10)', 4326));
INSERT INTO @temp values ('LineString', geography::STGeomFromText(
'LINESTRING(13 5, 50 25)', 4326));
--Calculate the distance to a point on the LINESTRING.
--Display the number of dimensions for a geography object stored in a --table variable.
INSERT INTO @temp values ('Polygon', geography::STGeomFromText(
'POLYGON((47.653 -122.358, 47.649 -122.348, 47.658 -122.348, 47.658 -122.358, 47.653 -122.358))', 4326));

SELECT [name], [geom].STDimension() as [dim]
FROM @temp;

--Results
--name       dim
------------ -----------
--Point      0
--LineString 1
--Polygon    2

J'espère que ces informations sur les sept nouveaux types de données de SQL Server 2008 vous ont été utiles.

Kelly Wilson travaille dans le secteur de l'ingénierie logicielle depuis plus de 20 ans. Son palmarès inclut des applications dans des domaines tels que SQL Server, les graphiques 3D, les jeux et les sciences de la couleur. Kelly est actuellement rédactrice en programmation au sein du groupe SQL Server de Microsoft.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.