SQL Server UDT-Größen 2005 bis 2008

Question

In SQL Server 2005 haben wir einige UDT (User Defined Datatypes) definiert, insbesondere SK (für Surrogate Key).Diese wurden als 32-Bit-Int definiert.Und folglich betrug die Größe 4 Bytes.

In SQL Server 2008 verwendet der UDT für die Ganzzahl-Datentypen je nach Genauigkeit einen anderen Speichermechanismus:

Der Speicher zeigt die maximale Speichergröße für die UDT an.Die maximalen Speichergrößen variieren je nach Präzision.

Genauigkeit (Ziffern)....Speicher (Bytes)

1 – 9........................5

10 – 19....................9

20 – 28...................13

29 – 38...................17

Eine Folge davon ist, dass UDTs, die SOWOHL auf int als auch auf bigint basieren, 9 Bytes belegen!NOTIZ:Die nativen Datentypen int und bigint belegen immer noch 4 bzw. 8 Byte!

9 Bytes scheinen für einen Ersatzschlüssel-UDT ziemlich schwer zu sein!

Kann jemand erklären, warum das so ist (insbesondere, was die Designbegründung dafür war)?Wie kommt es zu dieser Diskrepanz zwischen UDT und nativen Datentypen?

Gibt es alternative Ansätze außer der KEINEN Verwendung von UDTs?

Answer 1

Entschuldigen Sie, aber mir scheint, Sie haben etwas falsch verstanden.Denken Sie daran: „SELECT ist nicht kaputt“ und Microsoft wird einen so kritischen Teil seiner Engine nicht ändern, ohne dies aufgrund von Konvertierungsproblemen deutlich zu machen.

Die Tabelle, die Sie zitieren, stammt aus Dezimal Und numerisch Lagerung in MSDN, das sind im Grunde mehr als int

Wenn Sie einen strengen Alias ​​verwenden, Verwendung spezieller Datentypen deutet stark darauf hin, dass a int-basierter Typ benötigt vier Bytes und nicht mehr.Wenn Sie einen CLR-Typ verwenden, gibt es Drachen oder mehr Overhead.

Wie auch immer, Sie können den Footprint Ihrer Datentypen überprüfen, indem Sie einen Blick darauf werfen sys.types