it-swarm.com.de

datetime2 (0) vs datetime2 (2)

Laut Dokumentation datetime2 (Transact-SQL) :

Speichergröße
6 Bytes für Genauigkeiten unter 3.
7 Bytes für die Präzisionen 3 und 4.
Alle anderen Präzisionen erfordern 8 Bytes.

Die Größe von datetime2(0), datetime2(1), datetime2(2) verwendet dieselbe Speichermenge (6 Byte).

Würde ich zu Recht sagen, dass ich genauso gut mit datetime2(2) arbeiten und den Vorteil der Präzision ohne zusätzliche Größenkosten nutzen könnte?

Bitte beachten Sie:

  • Diese Spalte wird mit der PK indiziert, um einen zusammengesetzten Clustered-Index zu bilden (der für die Tabellenpartitionierung verwendet wird).
  • Millisekunden sind mir egal

Wäre datetime2(0) effizienter, wenn es in einer where-Klausel verwendet wird oder wenn ein Index durchsucht wird?

Dies ist eine riesige Tabelle, daher wird die kleinste Optimierung einen großen Unterschied machen.

16
Zapnologica

Die Größe von dateTime2 (0), dateTime2 (1), dateTime2 (2), dateTime2 (3) verwendet dieselbe Speichermenge. (6 Bytes)

Würde ich zu Recht sagen, dass ich genauso gut mit dateTime2 (3) arbeiten und den Vorteil der Präzision ohne zusätzliche Größenkosten nutzen könnte?.

Nein, Sie haben die Dokumentation falsch interpretiert. Beachten Sie, dass das Dokument Speichergröße 6 Byte für Präzisionen kleiner als 3 (Hervorhebung meiner) angibt. Eine Genauigkeit von 3 erfordert also 7 Bytes.

Wenn Sie sich nicht für Millisekunden interessieren, ist datetime2(0) der richtige Datentyp und die richtige Genauigkeit. Die beste Vorgehensweise besteht darin, den richtigen Datentyp und die richtige Genauigkeit basierend auf den gespeicherten Daten anzugeben, da dies von Natur aus eine optimale Speicherung und Effizienz bietet. Abgesehen davon würde ich keine signifikanten Auswirkungen auf die Leistung aufgrund der angegebenen datetime2-Genauigkeit erwarten, solange die Speichergröße gleich ist, aber ich habe dies selbst nicht speziell getestet.

Die Anwendungsanforderungen bestimmen, was in der Datenbank gespeichert werden muss, wenn eine höhere Genauigkeit in der Quelle verfügbar ist. Beispielsweise möchten Benutzer für eine Auftragseingabezeit aus SYSDATETIME() möglicherweise keine Genauigkeit von 100 Nanosekunden. Wählen Sie erneut den Datentyp und die Genauigkeit für die Neuentwicklung gemäß den Anforderungen, und Sie erhalten im Allgemeinen eine optimale Leistung ohne zusätzliche Überlegungen:

  • Datum - Sie brauchen keine Zeit
  • smalldatetime - Sie brauchen keine Sekunden
  • datetime2 (0) - Sie benötigen keine Sekundenbruchteile
  • datetime2 (1-7) - Sie benötigen Sekundenbruchteile der angegebenen Genauigkeit
  • datetimeoffset (0-7) - Sie benötigen Datum und Uhrzeit mit Zeitzonenerkennung
  • Zeit (0-7) - Sie benötigen nur Zeit (kein Datum) mit Sekundenbruchteilen der angegebenen Genauigkeit

Obwohl datetime2 für die oben aufgeführte Neuentwicklung am besten geeignet ist, muss manchmal datetime (feste Genauigkeit 3 ​​mit einer Genauigkeit von 1/300 Sekundenbruchteilen) verwendet werden, um die Kompatibilität mit älteren datetime-Anwendungen zu gewährleisten und implizite Konvertierungen zu vermeiden und unerwartetes Vergleichsverhalten, jedoch auf Kosten der Sekundenbruchteilgenauigkeit und der erhöhten Speicherkapazität.

Bedenken Sie, dass das Speichern einer höheren Präzision als erforderlich auch Entwicklungskosten verursachen kann. Wenn eine Zeitkomponente mit Sekundenbruchteilen gespeichert wird, für die nur eine Genauigkeit von einer ganzen Sekunde erforderlich ist, müssen Abfragen weiterhin die Sekundenbruchteile berücksichtigen, um die richtigen Ergebnisse zurückzugeben. Bei einer App, bei der der Benutzer einen Zeitbereich über eine Benutzeroberfläche auswählt, die nur ganze Sekunden zulässt, müsste der App-Code beispielsweise die Sekundenbruchteile im Endzeitbereichswert berücksichtigen und den vom Benutzer angegebenen Wert entsprechend anpassen (z WHERE OrderEntryTime BETWEEN '2017-01-11T08:00:00.00.00' AND '2017-01-11T08:59:59.99' oder WHERE OrderEntryTime >= '2017-01-11T08:00:00.00' AND OrderEntryTime < '2017-01-11T09:00:00.00'). Dies erhöht die Codekomplexität.

28
Dan Guzman