Wenn Sie SQL Server & ASP.NET verwenden, gibt es eine Performance-/Speicherüberlegung bei Verwendung von Date vs DateTime?Gibt es bei der Verwendung von Date vs. DateTime einen Unterschied bei der Leistung oder dem Speicher?
Auch wenn ich es nicht brauchen, ich habe DateTime benutze für die meisten Dinge
Datetime dauert 8 Bytes pro Wert
Datum 3 Byte.
Ich kann nicht für niedrige Leistung sprechen; Im Allgemeinen haben wir es jedoch als Fehler empfunden, Werte standardmäßig als DateTime zu speichern. Früher oder später stößt man auf das UTC-Problem und muss Offsets für Datumsangaben mit 00: 00: 00.000 im Zeitabschnitt erstellen!
Wenn Sie nur Daten speichern, würde ich den Datentypen Date beibehalten; Sie passen mehr Zeilen pro Seite an und sparen sich viel Ärger
Hängt davon ab, wie viele Zeilen Sie speichern und wofür Sie sie verwenden. Datum ist 3 Bytes, DateTime ist 8 Bytes. Kann sich schnell addieren, wenn Sie Milliarden von Datenzeilen haben oder für einen Index verwenden. Natürlich gibt es einen Unterschied in der Auflösung des gespeicherten Wertes. Es gibt auch andere Datumstypen zwischen Datum und Datum, z. B. smalldatetime, die kompakter sind, wiederum mit unterschiedlichen Kompromissen.
Überlegungen:
DATE Typ wurde in SQL Server 2008 eingeführt, so dass Ihre Anwendung ist nicht kompatibel mit SQL Server 2005 nicht mehrDate Klasse in .NET - DATE wird umgewandelt in DateTime .NET-KlassenDATE SQL-TypDATETIME zuschneiden können tun CAST(@myDateTimeParam AS DATE)aus meiner Erfahrung: Ich mag diese neue Art und hatte keine Probleme mit ihm während der Programmierung T-SQL oder C#
sich dessen bewusst sein (Mischdatentypen für dat e auf comparition):
DECLARE @startDay DATE = '2012-04-11' -- day
DECLARE @endDay DATE = '2012-04-13' -- day
DECLARE @eventTime DATETIME = '2012-04-13 12:00' -- point in time (noon)
IF @eventTime BETWEEN @startDay AND @endDay PRINT 'In period.' ELSE PRINT 'Not in period!'
Ergebnis ist:
Not in period!
Auf BETWEEN comparition @endDay wurde in der Zeit (Punkt zu DATETIME gegossen unten; der gemeinsame Typ mit @eventTime), denke ich - was gibt ein nicht intuitives Ergebnis.
Vergleichen mit:
DECLARE @startDay DATE = '2012-04-11' -- day
DECLARE @endDay DATE = '2012-04-13' -- day
DECLARE @eventTime DATE = '2012-04-13' -- day
IF @eventTime BETWEEN @startDay AND @endDay PRINT 'In period.' ELSE PRINT 'Not in period!'
Ergebnis:
In period.
Und mit ihm:
DECLARE @startDay DATETIME = '2012-04-11' -- day, but point in time in fact 00:00.000
DECLARE @endDay DATETIME = '2012-04-13' -- day, but point in time in fact 00:00.000
DECLARE @eventTime DATETIME = '2012-04-13' -- day, but point in time in fact 00:00.000
IF @eventTime BETWEEN @startDay AND @endDay PRINT 'In period.' ELSE PRINT 'Not in period!'
Ergebnis:
In period.
Dies ist ein Es hängt auch davon ab, was der Kontext von "Datum" ist und ob es TZ-bewusst sein muss (mein Freitag ist vielleicht nicht Ihr Freitag). Nicht das Speichern von allem als UTC ist viel besser ... da es immer noch nicht das TZ selbst erfasst. Es gibt auch einen 'DATETIMEOFFSET' Typ; Allerdings weiß ich nicht, wie es zu .NET zugeordnet ist :( –
@ Click-Rex können Sie bitte Ihren Kontext erklären? – Pankaj
DateTime ist nur "lokale Zeit" - es hat keine Ahnung von Zeitzone Präsentation. Es bedeutet, dass Sie wissen müssen In welcher Zeitzone es geschrieben wurde, damit Sie es genau entschlüsseln können. Auch dort gibt es eine ganze Reihe von Problemen wie die Sommerzeit. Hier kommt der Kommentar zu UTC ins Spiel - alle Apps würden Daten in UTC für die Speicherung und zurück zu Lokale Zeit für die Anzeige Klingt einfach? Nicht wirklich - es ist wirklich ziemlich schwierig, alle Apps ohne viel absichtlichen Aufwand und Tests zu bekommen. DateTimeOffset Typ wurde eingeführt, um das Problem zu beheben. – stephbu