none
Consejos básicos sobre uso óptimo de tipos de datos SQL SERVER. RRS feed

  • Pregunta

  • Buenos días,

    Estoy tratando de establecer un listado de consejos y reglas básicas para un mejor uso de tipos de datos en SQL SERVER, de momento queda asi, pero me gustaria conocer su opinión, posibles errores de bulto y otros consejos basicos que consideren que tendrían que estar en un listado de esta indole.

    Muchas gracias.

    Establecemos por tanto los siguientes consejos y reglas básicas en el uso de tipos de datos SQL SERVER:

    -Utilizar siempre que sea posible el tipo de dato que menor espacio ocupe en la base de datos.

    -Utilizar cadenas de caracteres lo menos posible, (únicamente cuando estemos ante textos), todo valor convertible a numéricos o fechas y hora deberá estar en estos formatos y no en cadenas de caracteres.

    -Respecto a numéricos exactos si conocemos la naturaleza del número a almacenar, utilizar la menor posible, por ejemplo, con una columna de edad de personas con tinyint será suficiente, o para almacenar el año de una fecha concreta con smallint nos valdrá.

    -En cuanto al uso especifico de cadenas de caracteres, priorizar char sobre varchar y a su vez priorizar estos sobre sus versiones Unicode nchar y nvarchar, básicamente porque ocupan menos espacio, si tenemos la seguridad de que la cadena de texto va a tener longitud exacta utilizamos char, en caso contrario varchar.

    Ejemplos:

    Columna con el sexo de las personas codificado como V(Varón) o H(Hembra), al ser siempre un único carácter utilizaremos char (1).

    Columna con los nombres de las personas, utilizaremos a la fuerza varchar (n), siendo esta n un valor que consideremos lo suficientemente grande. Si por ejemplo esperamos encontrar caracteres Unicode dentro de estos nombres tendríamos que utilizar nvarchar (n).

    -Algunos de los tipos de datos de SQL SERVER son parametrizables y en caso de falta de parámetro dado por el usuario se establece un valor por defecto que puede no convenirnos, por tanto, si conocemos la naturaleza exacta del dato utilizar la configuración de parámetros que ocupen el menor espacio posible para ese tipo de dato.

    Ejemplos:

    Queremos dar las horas, minuto y segundos de una hora (HH:MM:SS) utilizaremos para ello el tipo de dato time(ns), sin embargo por defecto time, es time (7) que nos daría este formato 00:00:00.0000000 que ocupa 5 bytes ,mientras que nosotros lo que queremos y que ocupa menos (3 bytes) es time(0) 00:00:00

    viernes, 12 de marzo de 2021 12:02

Todas las respuestas

  • Hola AngelBazan:

    El documento está bien, no tiene ningún error de bulto, pero en SQL no todo es el tamaño, a veces también hay que anticiparse a lo que pueda ocurrir o presentar la mejor solución que nos evite problemas.

    o para almacenar el año de una fecha concreta con smallint nos valdrá.

    Un ejemplo bastante común es el que detallas, pero suele ocurrir que más tarde desde dirección de negocio, te solicitan el mes. No es que añadir una nueva columna sea costoso pero si hubieras escogido un tipo de datos date, ya ocuparías el mismo espacio que con el nuevo requerimiento, y solo tendrías que añadir un cambio en una consulta. De la otra manera siempre, hay mucho más trabajo que hacer y no puedes ofrecer esa información desde que te lo piden.

    Otro punto caliente son los nvarchar.

    Si por ejemplo esperamos encontrar caracteres Unicode dentro de estos nombres tendríamos que utilizar nvarchar (n)

    Esos nombres aparecen cuando no te los esperas. Siempre que depende de información obtenida del usuario, uno no se espera que un nombre se escriba con un carácter especial, o sobre todo si la información se cubre directamente por él.

    Siempre es una opinión, pero por lo demás, me parece perfecto.

    sábado, 13 de marzo de 2021 7:02