Escogiendo tipos de Datos en SQL Server 2000
Escoger un tipo de dato es demasiado importante, por causa de los errores en un diseno de tablas mal hecho puede dar como resultado una degradación del desempeño tremenda. Yo he encontrado esos problemas muchas veces cuando he tenido que manejar gran cantidad de datos tanto en la inserción, actualización y selección de filas. En este artículo se definirán algunas cosas como los tipos built-in y los user-defined, el cómo SQL Server 2000 almacena los datos en una data page, y presentar algunos consejos generales para escoger un tipo de dato apropiado.
Tipos de Datos "Built-in"
En Microsoft SQL Server 2000, cada objeto (como una columna, variable o parámetro) tiene un tipo de dato relacionado, funciona como un atributo que especifica el tipo de dato que el objeto puede almacenar. SQL Server 2000 llegó a nuestras manos con 27 tipos de datos built-in (system). Los cuales son:
| Data Types | Description |
|---|---|
| bigint | Integer data from -2^63 through 2^63-1 |
| int | Integer data from -2^31 through 2^31 - 1 |
| smallint | Integer data from -2^15 through 2^15 - 1 |
| tinyint | Integer data from 0 through 255 |
| bit | Integer data with either a 1 or 0 value |
| decimal | Fixed precision and scale numeric data from -10^38 +1 through 10^38 -1 |
| numeric | Fixed precision and scale numeric data from -10^38 +1 through 10^38 -1 |
| money | Monetary data values from -2^63 through 2^63 - 1 |
| smallmoney | Monetary data values from -214,748.3648 through +214,748.3647 |
| float | Floating precision number data from -1.79E + 308 through 1.79E + 308 |
| real | Floating precision number data from -3.40E + 38 through 3.40E + 38 |
| datetime | Date and time data from January 1, 1753, through December 31, 9999, with an accuracy of 3.33 milliseconds |
| smalldatetime | Date and time data from January 1, 1900, through June 6, 2079, with an accuracy of one minute |
| char | Fixed-length character data with a maximum length of 8,000 characters |
| varchar | Variable-length data with a maximum of 8,000 characters |
| text | Variable-length data with a maximum length of 2^31 - 1 characters |
| nchar | Fixed-length Unicode data with a maximum length of 4,000 characters |
| nvarchar | Variable-length Unicode data with a maximum length of 4,000 characters |
| ntext | Variable-length Unicode data with a maximum length of 2^30 - 1 characters |
| binary | Fixed-length binary data with a maximum length of 8,000 bytes |
| varbinary | Variable-length binary data with a maximum length of 8,000 bytes |
| image | Variable-length binary data with a maximum length of 2^31 - 1 bytes |
| cursor | A reference to a cursor |
| sql_variant | A data type that stores values of various data types, except text, ntext, timestamp, and sql_variant |
| table | A special data type used to store a result set for later processing |
| timestamp | A database-wide unique number that gets updated every time a row gets updated |
| uniqueidentifier | A globally unique identifier |
Algunos de estos tipos de datos (bigint, sql_variant y table) están disponibles únicamente en SQL Server 2000, mientras que los demás han sido características ya presentes en las anteriores versiones de SQL Server.
Tipos de datos definidos por el usuario: "User-defined"
SQL Server 2000 soporta tipos de datos definidos por el usuario también. Estos tipos de datos proveen un mecanismo para aplicar un nombre a un tipo de dato que es más descriptivo que los tipos de valores a ser contenidos por el objeto. Usar los tipos de dato definidos por el usuario puede facilitar que un administrador de base de datos o un programador pueda entender el uso e intencíon de cualquier objeto definido con el tipo de dato. Estos tipos de datos estan basados en los "system data types" y pueden ser usados para predefinir atributos de una columna, como el tipo de dato, tamaño (length) e inclusive aceptar valores nulos (NULL). Para crear un tipo de dato definido por el usuario (user-defined data type) se puede utilizar el stored procedure de sistema: sp_addtype o se puede agregar mediante la interfaz gráfica del Enterprise Manager. Con el siguiente ejemplo creamos un tipo de dato definido por el usuario basado en el tipo de dato "money" le damos el nombre de cursale que no puede ser nulo: EXEC sp_addtype cursale, money, 'NOT NULL' Tanto el tipo de dato de sistema (system) como el definido por el usuario (user-defined) son usados para asegurar la integridad de datos. Es muy importanto que pongamos todo el esfuerzo posible mientras diseñamos las tablas de nuestra base de datos: mientras mejor diseñadas estén las tablas, mucho más tiempo podremos trabajar sin ningún problema de desempeño. En el caso ideal (?), nunca deberíamos actualizar la estructura de las tablas.
Consejos para escoger tipos de datos apropiados.
SQL Server 2000 almacena los datos en estructuras especiales llamadas "data pages" que son de 8KB (8192 bytes) de tamaño. Algo de espacio de los data pages es usado para guardar información de systema, el cual libera 8060 bytes para almacenar los datos de usuario. Así, si el tamaño de una fila de una tabla es de 4040 bytes, entonces solamente una fila podrá ser colocada en cada data page. I se puede reducir el tamaño de la fila a 4030 bytes, se pueden guardar dos filas por cada page data. Mientras menos espacio sea usado, más pequeño será la tabla y el index y por ende menor el I/O que el Servidor SQL Server tendrá que realizar cuando lea las páginas del disco. De esta manera, se debería diseñar las tablas con la finalidad de maximizar el número de filas que pueden ser almacenadas en un data page, especificar las columnas lo más estrechas posibles. Mientras más angostas sean las columnas, menos los datos almacenados y más rapidez para el SQL al leer y escribir datos. Como recomendación podemos probar con estos consejos al escoger tipos de datos:
- Si se necesita almacenar datos enteros desde 0 hasta 255, usar el tipo de dato tinyint.
Las columnas con tipos de datos tinyint usan solamente 1 byte para almacenar sus valores, en comparación con 2 bytes, 4 bytes y 8 bytes usados para guardar las columnas con smallint, int y bigint respectivamente. - Si se necesita guardar datos enteros desde -32,7658 hasta 32,767, usar smallint.
Las columnas con tipo de dato smallint usan solamente 2 bytes para almacenar sus valores, a diferencia de los 4 bytes y 8 bytes de los tipos de datos int y bigint respectivamente. - Si se necesita almacenar datos enteros desde -2,147,483,648 hasta 2,147,483,647, usar int.
Las columnas con tipo de dato int usan solamente 4 bytes para guardar sus valores, mientras que los bigint usan 8 bytes. Se puede utilizar si es que por ejemplo se necesita catalogar una biblioteca con más de 32,767 libros. - Usar smallmoney en vez de money, si se necesita guardar valores monetarios desde -214,748.3648 hasta 214,748.3647.
Las columnas con tipo de dato smallmoney usan solamente 4 bytes para guardar sus valores, en comparación con los 8 bytes que son usados cuando las columnas tienen tipo de dato money. Por ejemplo si necesitas almacenar los sueldos mensuales de los empleados. - Usar smalldatetime en vez de datetime, si se necesita guardar la fecha y hora desde Enero 1 de 1900 hasta Junio 6 del 2079, con exactitud al minuto.
Las columnas con smalldatetime usan solamente 4 bytes para guardar sus valores, en comparación con los 8 bytes usados para guardar valores de las columnas con datetime. Si necesitas almacenar la fecha de ingreso de un empleado a la compañía utiliza este tipo de dato. - Usar columnas varchar/nvarchar en vez de text/ntext cuando sea posible.
Porque SQLServer almacena las columnas text/ntext en las páginas de tipo Text/Image separado del resto de datos que están en las páginas de Datos, esto hace que tome más tiempo obtener los valores text/ntext. - Usar columnas char/varchar en vez de nchar/nvarchar si es que no se necesita almacenar datos unicode.
Los valores char/varchar usan solamente 1 byte para guardar cada caracter, los valores nchar/nvarchar usan 2 bytes para almacenar un caracter, así que el tipo de dato char/varchar usa dos veces menos espacio de almacenamiento en comparación a nchar/nvarchar.











Muy util, muchas gracias!