TechNet Magazine > Inicio > Todos los números > 2008 > April >  SQL Server 2008: Nuevos tipos de datos
SQL Server 2008
Nuevos tipos de datos
Kelly Wilson
 
Resumen:
  • Nuevos tipos de datos date y time
  • Representación de posiciones en una jerarquía
  • Dos modelos para trabajar con datos espaciales

El aumento de la actividad profesional en la economía global requiere que las compañías usen nuevos tipos de datos, aplicaciones y cálculos complejos. Los siete nuevos tipos de datos integrados en SQL Server 2008
proporcionan los medios para trabajar y simplificar la administración de datos más complicados.

Date y time
Con el antiguo tipo de datos datetime, los usuarios de SQL Server® no tenían capacidad para trabajar con información de fecha y hora de forma independiente. Cuatro de los nuevos tipos de datos, date, time, datetime2 y datetimeoffset, simplifican el trabajo con datos de fecha y hora y ofrecen un mayor intervalo de fechas, precisión de fracciones de segundo y compatibilidad para zonas horarias. Las nuevas aplicaciones de bases de datos deben usar esos nuevos tipos de datos en lugar del datetime heredado. Analicemos con mayor profundidad las versiones nuevas.
El tipo de datos date almacena una fecha sin un componente de hora. El intervalo comprende desde el 1 de enero, 1000 hasta el 31 de diciembre, 9999 (01-01-0001 a 31-12-9999). Todas las variables date requieren 3 bytes de almacenamiento y tienen una precisión de 10 dígitos. La precisión del tipo date se limita a un único día.
Observe la Figura 1, que muestra cómo crear e inicializar variables de fecha en scripts T-SQL. Una cadena con formato 'MM/DD/AAAA' inicializa la variable @myDate1. La variable @myDate2 no se inicializa; tendrá un valor NULL. La variable @myDate3 se inicializa con la fecha del sistema del equipo local. El valor de las variables se puede cambiar en cualquier momento mediante las instrucciones SELECT o SET, como se muestra en el ejemplo, cambiando el valor de @myDate2. Las columnas de fecha también se pueden crear en tablas. La Figura 2 muestra cómo crear una tabla con tres columnas de fecha.
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

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

El tipo de datos time almacena la hora del día sin ningún componente de fecha. Se basa en un reloj de 24 horas, por lo que el intervalo admitido abarca de 00:00:00.0000000 a 23:59:59.9999999 (horas, minutos, segundos y fracciones de segundo). Puede especificar una precisión de fracciones de segundo al crear el tipo de datos. La precisión predeterminada es 7 dígitos; la precisión es 100ns. La precisión afecta al espacio de almacenamiento necesario, que varía desde 3 bytes hasta 2 dígitos; 4 bytes para 3 o 4 dígitos y hasta 5 bytes de 5 a 7 dígitos.
El script T-SQL de la Figura 3 muestra cómo se ve afectada la precisión de la variable por las conversiones implícitas de un valor de inicialización de una cadena. El código T-SQL primero crea e inicializa ocho variables de hora independientes en un valor idéntico. La precisión fraccionaria de cada variable es equivalente a su nombre. Por ejemplo, @myTime3 tiene una precisión fraccionaria de tres dígitos. Los resultados muestran que la precisión de cada tipo de datos time es equivalente a la precisión fraccionaria con la que se declara. Los dígitos que caen fuera del intervalo están truncados.
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 tipo de datos time se puede crear como una columna en una tabla. El script T-SQL DROP TABLE myTable de la Figura 4 crea una tabla llamada myTable1 y agrega tres columnas de tiempo a la tabla. A continuación, se inserta un registro en la tabla y los contenidos de la tabla se muestran con una instrucción SELECT.
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 y Datetime2
El tipo de datos datetimeoffset proporciona reconocimiento de zonas horarias. El tipo de datos time no contiene una zona horaria por lo que sólo funciona en hora local. En la economía global, sin embargo, a menudo es necesario saber cómo se relacionan las distintas zonas horarias entre sí. El desplazamiento de zona horaria se indica como + o - hh:mm.
Este código crea una variable datetimeoffset y la inicializa con el valor de hora 8:52 A.M., hora estándar del Pacífico:
DECLARE @date DATETIMEOFFSET = '2007-11-26T08:52:00.1234567-08:00'
PRINT @date
--Results
--2007-11-26 08:52:00.1234567 -08:00
La cadena que inicializa la variable datetimeoffset (@date en el script) dispone de un formato especial, ordenada desde el elemento más importante al menos. Una única letra mayúscula T separa los elementos de fecha y hora. Un signo menos separa los elementos de hora de la zona horaria. No hay espacios entre el signo menos y los elementos de hora o de zona horaria. Este formato es uno de los formatos ISO 8601 admitidos por el tipo de datos datetimeoffset. ISO 8601 es una norma internacional para la representación de valores de fecha y hora.
La precisión del componente de hora se especifica como el tipo de datos time, y si no se especifica, su valor predeterminado son los mismos siete dígitos. El intervalo admitido es el mismo.
El tipo de datos datetime2 es una extensión del tipo datetime original. Admite un intervalo de fechas mayor y una precisión fraccionaria de segundos superior. Asimismo, le permite especificar la precisión. El intervalo de fechas del tipo datetime2 comprende desde el 1 de enero, 0001 hasta el 31 de diciembre, 9999, comparado con el intervalo de datetime original del 1 de enero, 1753 al 31 de diciembre, 9999. Como con el tipo de datos time, se proporciona una precisión de siete fracciones de segundo. El tipo datetime original proporcionó tres dígitos de precisión y un intervalo de tiempo de 00:00:00 a 23:59:59.999. A continuación, se muestra cómo crear una variable datetime2 e inicializarla para la fecha y la hora del servidor local:
DECLARE @datetime2 DATETIME2 = GetDate();
PRINT @datetime2

--Results
--2007-11-26 09:39:04.1370000
Echemos un vistazo al tipo de datos hierarchyid. Este tipo de datos trabaja con las relaciones entre los elementos de datos de una tabla, en lugar de con datos específicos de fecha u hora.

Tipo de datos hierarchyid
El tipo de datos hierarchyid le permite construir relaciones entre los elementos de datos de una tabla, sobre todo para representar una posición en una jerarquía. Para explorar este tipo de datos, empecemos creando la base de datos MyCompany y rellenándola con los datos de los empleados mediante el script de la Figura 5.
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 Figura 6 muestra la base de datos resultante formada por una única tabla de empleados. Esta tabla de empleados de MyCompany no dispone de ninguna estructura impuesta. Esto es habitual en las bases de datos relacionales, ya que la estructura se impone de forma dinámica por una aplicación a través de su código de procesamiento y consulta.
Figura 6 Tabla de empleados de MyCompany 
Datos de negocio, aunque, normalmente dispone de un tipo de estructura inherente. Por ejemplo, todos los negocios disponen de una estructura para despachar con los miembros del organigrama, como se muestra en el caso de MyCompany en la Figura 7. Todos los empleados de MyCompany despachan con Juan, el Director general. Algunos empleados despachan con él directamente, como en el caso de Isabel. Otros, como María se comunica con él a través de un intermediario. En términos de programación, la estructura para despachar con los miembros del organigrama de MyCompany se conoce como árbol, ya que ésa es la forma que tiene. Juan, en la parte superior, no informa a nadie; es el padre o antecesor. Los empleados que despachan con Juan se encuentran por debajo. Esos nodos se denominan hijos o descendientes. Juan puede tener tantos nodos descendientes como necesite para representar sus informes directos.
Figura 7 Estructura organizativa de MyCompany (Hacer clic en la imagen para ampliarla)
El script de la Figura 8 recrea la base de datos de MyCompany mediante el tipo de datos hierarchyid, creando una relación que coincide con la estructura para despachar con los miembros del organigrama de MyCompany. La instrucción ALTER TABLE se usa primero para agregar una columna de tipo hierarchyid. El nodo de Juan se inserta a continuación mediante el método GetRoot de hierarchyid. Los descendientes de Juan se agregan al árbol mediante el método GetDescendant.
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

Una vez agregados los registros de base de datos y construida la jerarquía, se pueden mostrar los contenidos de la tabla de empleados con una consulta como esta:
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 es la columna hierarchyid. Cada carácter de barra diagonal / del resultado indica un nodo en el árbol jerárquico. Juan está en la raíz, que se muestra con una única barra diagonal. Nuria, Jesús e Isabel despachan con Juan y tienen dos barras diagonales que indican que son el segundo nodo de la jerarquía. Los números 1, 2 o 3 muestran el orden de cada nodo secundario respectivamente. Este sistema es muy flexible. Los nodos secundarios se pueden eliminar, insertar o agregar según sea necesario. Si agregamos un empleado entre Jesús e Isabel, por ejemplo, ese empleado aparecerá en el conjunto de resultados como: /2.1/.
Para responder la pregunta "¿Quién despacha con Nuria?" puede crear una consulta como se muestra en el siguiente código T-SQL:
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 consulta usa el método GetAncestor de hierarchyid, que devuelve el padre del actual nodo de hierarchyid. En el código anterior, la variable @Nuria se establece para el nodo de jerarquía para Nuria. Este es el motivo por el que Nuria es el antecesor directo de cualquier empleado que despache con ella. Por lo tanto, escribir una consulta que devuelva los empleados que despachan directamente con Nuria consiste en recuperar el nodo de Nuria del árbol y, a continuación, seleccionar todos los empleados cuyo nodo antecesor sea el nodo de Nuria.
Las columnas del tipo hierarchyid tienden a ser muy compactas debido a que el número de bits necesario para representar un nodo en un árbol depende del número medio de hijos que corresponden al nodo (normalmente denominados nodos secundarios del nodo). Por ejemplo, un nodo nuevo en una jerarquía organizativa de 100.000 empleados, con un promedio de nodos secundarios de seis niveles, necesitaría un almacenamiento de cinco bytes.
El tipo de datos hierarchyid ofrece varios métodos que facilitan el trabajo con datos jerárquicos. En la Figura 9 se muestra un resumen de estos métodos. En los Libros en pantalla de SQL Server encontrará información detallada acerca de estos métodos (msdn2.microsoft.com/ms130214).

Método Descripción
GetAncestor Devuelve un tipo de datos hierarchyid que representa el antecesor nth del nodo hierarchyid.
GetDescendant Devuelve un nodo secundario del nodo hierarchyid.
GetLevel Devuelve un entero que representa la profundidad del nodo hierarchyid en la jerarquía general.
GetRoot Devuelve el nodo hierarchyid raíz de este árbol de jerarquía. Static.
IsDescendant Devuelve true si el nodo secundario es un descendiente del nodo hierarchyid.
Parse Convierte una representación de cadena de una jerarquía en un valor de hierarchyid. Static.
Reparent Mueve el nodo de una jerarquía a una nueva ubicación dentro de la jerarquía.
ToString Devuelve una cadena que contiene la representación lógica de este hierarchyid.

Tipos de datos espaciales
Los datos espaciales son datos que identifican ubicaciones y formas geográficas, principalmente en la Tierra. Éstas ubicaciones pueden ser lugares de referencia, carreteras o incluso empresas. SQL Server 2008 proporciona los tipos de datos geography y geometry para trabajar con estos tipos de datos.
Los tipos de datos geography trabajan con información sobre una superficie elipsoidal. Este modelo de superficie elipsoidal tiene en cuenta la superficie curva de la Tierra para sus cálculos. La información acerca de la posición se proporciona en términos de longitud y latitud. Este modelo es adecuado para aplicaciones como envíos transoceánicos, planeaciones militares y aplicaciones de corto alcance que hacen referencia a la superficie de la Tierra. Éste es el modelo que debe usar si sus datos se almacenan como latitudes y longitudes.
El tipo de datos geometry trabaja con el modelo de superficie plana. En este modelo, la Tierra se trata como una proyección plana que empieza en un punto conocido. El modelo de superficie plana no tiene en cuenta la forma elipsoidal de la Tierra, por lo que se usa principalmente para describir distancias cortas, por ejemplo, en una aplicación de base de datos que traza el interior de un edificio.
Los tipos geography y geometry se crean a partir de objetos vectoriales, especificados en formato Well-Known Text (WKT) o Well-Known Binary (WKB). Existen formatos de transporte para datos espaciales descritos por la Open Geospatial Consortium (OGC) Simple Features for SQL Specification. La Figura 10 enumera los siete tipos de objetos vectoriales admitidos por SQL Server 2008.

Objeto Descripción
Point Una ubicación.
MultiPoint Una serie de puntos.
LineString Una serie de cero o más puntos conectados por líneas.
MultiLineString Un conjunto de linestrings.
Polygon Un región contigua descrita por un conjunto de linestrings.
MultiPolygon Un conjunto de polígonos.
GeometryCollection Una recopilación de tipos geométricos.
Para crear un tipo geography con uno o más objetos vectoriales, declare primero el tipo geography en el script T-SQL, como se muestra en la Figura 11. A continuación, llame a uno de los métodos enumerados en la Figura 12 e introdúzcalo en la cadena de caracteres del objeto vectorial y el identificador de referencia espacial (SRID). SRID es el sistema de identificación de referencia espacial, definido por el European Petroleum Survey Group. Forma parte de un conjunto de estándares desarrollados para cartografía, topografía y almacenamiento de datos geodésico. Cada SRID identifica un tipo específico de elipsoide para usarla en los cálculos geográficos. Esto es necesario ya que la Tierra no es una esfera perfecta. SQL Server 2008 sólo puede realizar cálculos con SRID idénticos.

Método Descripción
STGeomFromText Crea cualquier tipo de instancia geography del texto de entrada.
STPointFromText Crea una instancia Point de geography del texto de entrada.
STMPointFromText Crea una instancia MultiPoint de geography del texto de entrada.
STLineFromText Crea una instancia LineString de geography del texto de entrada.
STMLineFromText Crea una instancia MultiLineString de geography del texto de entrada.
STPolyFromText Crea una instancia Polygon de geography del texto de entrada.
STMPolyFromText Crea una instancia MultiPolygon de geography del texto de entrada.
STGeomCollFromText Crea una instancia Geometry­Collection de geography del texto de entrada.
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))


Diferencias entre Geography y Geometry
Los tipos de datos geography y geometry están diseñados para trabajar con diferentes tipos de datos, por lo que hay diferencias clave que hay que tener en cuenta. Con el tipo de datos geometry, las distancias y las áreas se dan en la misma unidad de medida que las coordenadas de las instancias. Por ejemplo, la distancia entre dos puntos (0,0) y (6,8) siempre será 10 unidades. No ocurre lo mismo con el tipo geography, que trabaja con coordenadas elipsoidales expresadas en grados de latitud y longitud.
El tipo de datos GEOMETRY devuelve resultados incoherentes cuando las coordenadas se expresan como pares de latitud y longitud. El código T-SQL que aparece a continuación calcula la distancia entre los PUNTOS (90 0) y (90 180). Ambos puntos hacen referencia al Polo Norte, por lo que la distancia entre ellos debería ser 0. En el caso del tipo GEOMETRY la distancia calculada es 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
La orientación de los datos espaciales también es diferente para ambos tipos de datos. En el sistema plano usado en el tipo de datos geometry, la orientación del polígono no es un factor importante. Por ejemplo, un polígono con las coordenadas ((0, 0), (10, 0), (0, 20), (0, 0)) se considera el mismo polígono que ((0, 0), (0, 20), (10, 0), (0, 0)). Pero en el modelo de datos usado por el tipo de datos geography, un polígono no está claro sin una orientación específica. Considere, por ejemplo, un círculo alrededor del Ecuador. ¿El polígono descrito por este círculo se refiere al hemisferio norte o al sur? Lo importante es que al trabajar con los datos geography, la orientación y la ubicación deben describirse con precisión.
SQL Server 2008 también tiene algunas restricciones para el tipo de datos geography. Por ejemplo, cada instancia geography debe encajar dentro de un hemisferio. No se permiten objetos espaciales más grandes, provocarían la generación de un ArgumentException. Los tipos de datos Geography que requieren dos entradas devolverán un valor NULL si el resultado de los métodos no encaja en un sólo hemisferio.
SQL Server ofrece varios métodos que permiten operaciones en instancias de geography y geometry. La Figura 13 muestra algunos ejemplos acerca del uso de los métodos de SQL Server 2008 para trabajar con datos espaciales. Debido a restricciones de espacio, no puedo profundizar más en este tema, pero puede encontrar descripciones completas en los Libros en pantalla de SQL Server.
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

Espero que esta información acerca de los siete nuevos tipos de datos de SQL Server 2008 le haya resultado útil.

Kelly Wilson se ha dedicado a la ingeniería de software durante más de 20 años. Sus méritos incluyen aplicaciones de SQL Server, gráficos 3D, juegos y ciencia del color. Actualmente, Kelly es programadora del grupo SQL Server en Microsoft.
© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.
Page view tracker