Tailles SQL Server UDT 2005 à 2008

Question

Dans SQL Server 2005, nous avons défini certains types de types de données définis par l'utilisateur (UDT, User Defined Datatypes) notamment SK (pour Surrogate Key). Ceux-ci ont été définis comme 32 bits 'int'. Et par conséquent, la taille était de 4 octets.

Dans SQL Server 2008, l'UDT des types de données entiers utilise un mécanisme de stockage différent, en fonction de la précision:

Stockage      Affiche la taille de stockage maximale pour le type défini par l'utilisateur. Les tailles de stockage maximales varient en fonction de la précision.

Précision (chiffres) ..... Stockage (octets)

1 - 9 ........................ 5

10 - 19 .................... 9

20 - 28 ................... 13

29 - 38 ................... 17

Une conséquence de ceci est que les UDT basés sur BOTH int et bigint occuperont 9 octets! REMARQUE: les types de données nat int et bigint occupent toujours 4 et 8 octets respectivement!

9 octets semble assez lourd pour une clé de substitution UDT!

Quelqu'un peut-il expliquer pourquoi il en est ainsi (en particulier quelle en était la conception)? Comment se fait-il que cet écart entre les types de données UDT et natif?

Existe-t-il une autre approche en dehors de NE PAS utiliser les UDT?

Answer 1

Excusez-moi, mais il me semble que vous vous êtes trompé. Rappelez-vous, & SELECT; SELECT n’est pas cassé " Microsoft ne modifiera pas un élément aussi critique de son moteur sans en faire la publicité à cause de problèmes de conversion.

la table que vous citez provient du stockage décimal et numérique de MSDN , qui représentent en réalité plus de int

Si vous utilisez un alias strict, Utilisation de types de données spéciaux indique fortement qu'un type basé sur int prend quatre octets et pas plus. Si vous utilisez un type CLR, il peut y avoir des dragons ou plus de temps système.

Dans tous les cas, vous pouvez vérifier l’empreinte de vos types de données en consultant sys. types