2009-08-31 19 views
11

Für Sie Datenbank Design/Performance-Gurus da draußen.SQL Server Datetime vs Int-Schlüssel Leistung

Wenn Sie über eine Datenbank verfügen, die Finanzdaten für Geschäftsjahrsperioden verfolgen soll, ist es besser/mehr Leistung/klarer, Datumsbereichssuchen wie PaymentDate Between X and Y durchzuführen oder ist es besser, eine int Schlüsseltabelle mit darin definierten Geschäftsjahrsperioden und Kennzeichnung der Zahlungstabelle mit dem Zahlungsdatum und diesem Schlüssel, also wo die WHERE-Klausel ist FiscalPeriodID = X?

Ich bin sicher, für kleinere Datensätze ist es egal, aber nehmen wir an, dass diese Daten in Millionen von Zeilen sein werden.

Antwort

18

Ich beschäftige mich täglich mit Lagerhäusern in den Millionen von Reihen, und wir finden, dass intelligente Datumsschlüssel der Weg zu gehen sind. Dies ist im Format YYYYMMDD. Also alles 2008 zu finden, würden Sie tun:

select 
    * 
from 
    gl 
where 
    postdate between 20080101 and 20081231 

Mit einer indizierten Spalte dieses phänomenal schnell, sogar über eine Milliarde Zeilen. Dies zeigt auch auf eine Datumstabelle, so dass wir den Wochentag, Monatsnamen oder andere Informationen über Daten, die wir mit diesem Beitritt haben, anheften können.

Natürlich sind diese Warehouses normalerweise so gebaut, dass sie SSAS-Cubes (OLAP-Datenbanken) unterstützen, so dass die Datumstabelle zu unserer Datumsdimension wird. Es ist viel schneller, an einem int als an einem datetime teilzunehmen.

+0

HRM ja, jetzt, dass ich nehmen kann, was Sie geschrieben und Forschung es scheint, dass dies eine schöne Standardlösung ist, insbesondere in Kuben. – Eric

+1

Was ist mit 'Zeit' Teil? Was ist, wenn ich auch Zeit speichern muss? Ist es gut, ein separates Feld für die Zeit zu verwenden und es auch als interger zu speichern und die Konvertierung bei Bedarf durchzuführen? – Mahmoodvcs

+1

David Stein schrieb einen Artikel darüber. Er sagt, dass Datumsfeld bessere Leistung in SQL 2008 hat. Url: [http://www.made2mentor.com/2011/05/date-vs-integ-datatypes-as-primary-key-for-date-dimensions/] (http://www.made2mentor.com/2011/05/date-vs-integer-datatypes-as-primary-key-for-date-dimensions/) – Mahmoodvcs

0

Was Sie mit erheblich großen finanziellen Datensätzen machen, sind Datenwürfel.

Dies bezieht sich grundsätzlich auf den Prozess der Erstellung der Berichte, die Sie für jede Periode benötigen, historisch, so dass Sie diese where Klauseln nicht brauchen, Sie einfach die Daten für diesen Zeitraum anzeigen.

So ist es egal. Speichern Sie es jedoch und implementieren Sie eine historische Datenbank, die für die langfristige Berichterstattung effizienter ist.

Ich würde mit dem gespeicherten Datum direkt gegen den Eintrag gehen.

0

Wenn Sie smalldatetime verwenden können, hat es die gleiche Größe wie Integer - beide 4 Bytes. Und unter der Haube sind die Datetime-Datentypen ganze Zahlen.

Die ersten 2 Bytes von smalldatetime sind etwas wie die Anzahl der verstrichenen Tage seit vielleicht 1/1/1900 und die zweiten 2 Bytes sind etwas wie die Anzahl der seit Mitternacht verstrichenen Sekunden. (Dies ist möglicherweise nicht genau, aber Sie erhalten den Punkt.) Diese Datentypen sind also sehr effizient.

Ich denke, eine Where-Klausel gegen die Smalldatetime Feld wird in Ordnung sein.

2

Beachten Sie auch, was in der Tat ist das Datum Teil eines aktuellen Datetime oder small Feld ... Die 4-Byte-Ganzzahl, die Anzahl der Tage seit dem 1. Januar 1900 darstellt

Dies kann auf eine tatsächliche Datumzeit gegossen wird implizit, sehr schnell (da es genau der gleiche Wert ist wie die ersten vier Bytes eines 8-Byte-DateTime-Werts)

Sie können es auch in Where-Klauseln mit tatsächlichen Datetime-Werten verwenden, da die SQL Server-Engine implizit konvertiert eins zum anderen und wieder zurück.

Plus jeder possile Wert eines 32-Bit (4-Byte) integer ist ein gültiges Datetime (Mitternacht) für den internen SQL Server Datetime-Datentyp