Dimensioni UDT di SQL Server dal 2005 al 2008
-
22-07-2019 - |
Domanda
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?
Soluzione
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