Dimensioni UDT di SQL Server dal 2005 al 2008

Question

In SQL Server 2005, abbiamo definito alcuni UDT (tipi di dati definiti dall'utente) in particolare su SK (per Surrogate Key). Questi sono stati definiti come "int" a 32 bit. E di conseguenza la dimensione era di 4 byte.

In SQL Server 2008, l'UDT per i tipi di dati interi utilizza un diverso meccanismo di archiviazione, a seconda della precisione:

bagagli      Visualizza la dimensione massima di archiviazione per l'UDT. Le dimensioni massime di archiviazione variano in base alla precisione.

di precisione (cifre) ..... bagagli (byte)

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

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

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

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

Una conseguenza di ciò è che gli UDT basati su ENTRAMBI e bigint occuperanno 9 byte! NOTA: i tipi di dati nativi int e bigint occupano ancora rispettivamente 4 e 8 byte!

9 byte sembra piuttosto pesante per una chiave surrogata UDT!

Qualcuno può spiegare perché sia ??così (in particolare quale fosse la logica progettuale per questo)? Come mai questa discrepanza tra l'UDT e i tipi di dati nativi?

Esistono approcci alternativi oltre a NON utilizzare gli UDT?

Answer 1

Mi scusi, ma mi sembra che tu abbia sbagliato. Ricorda che " SELECT non è rotto " e Microsoft non modificherà un componente così critico del proprio motore senza pubblicizzarlo fortemente a causa di problemi di conversione.

la tabella che stai citando proviene da decimale e numerico in MSDN , che sono sostanzialmente più di int

Se si utilizza un alias rigoroso, Uso di tipi di dati speciali suggerisce fortemente che un tipo basato su int richiede quattro byte e non più. Se stai usando un tipo CLR, ci sono draghi o più overhead.

Ad ogni modo, puoi verificare l'impronta dei tuoi tipi di dati guardando sys. tipi