Pregunta

En SQL Server 2005, definimos algunos UDT (tipos de datos definidos por el usuario) en particular, era SK (para clave sustituta). Estos se definieron como 32 bits 'int'. Y, en consecuencia, el tamaño era de 4 bytes.

En SQL Server 2008, el UDT para los tipos de datos enteros usa un mecanismo de almacenamiento diferente, dependiendo de la precisión:

Almacenamiento      Muestra el tamaño de almacenamiento máximo para el UDT. Los tamaños máximos de almacenamiento varían según la precisión.

Precisión (dígitos) ..... Almacenamiento (bytes)

1 & # 8211; 9 ........................ 5

10 & # 8211; 19 .................... 9

20 & # 8211; 28 ................... 13

29 & # 8211; 38 ................... 17

¡Una consecuencia de esto es que los UDT basados ??en AMBOS int y bigint ocuparán 9 bytes! NOTA: ¡los tipos de datos nativos int y bigint todavía ocupan 4 y 8 bytes respectivamente!

¡9 bytes parecen bastante pesados ??para una UDT de clave sustituta!

¿Alguien puede explicar por qué esto es así (en particular, cuál fue la razón de diseño para esto)? ¿Cómo es que esta discrepancia entre el UDT y los tipos de datos nativos?

¿Hay enfoques alternativos además de NO usar UDT?

¿Fue útil?

Solución

Disculpe, pero me parece que se equivocó. Recuerde, "SELECCIONAR no está roto" y Microsoft no modificará una pieza tan crítica de su motor sin anunciarla fuertemente debido a problemas de conversión.

la tabla que está citando proviene del almacenamiento decimal y numérico en MSDN , que son básicamente más que int

Si usa un alias estricto, Uso de tipos de datos especiales sugiere que un tipo basado en int toma cuatro bytes y no más. Si está utilizando un tipo CLR, habrá dragones o más sobrecarga.

De todos modos, puede verificar la huella de sus tipos de datos mirando sys. tipos

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top