2009-08-31 12 views
11

Dla ciebie projektanta bazy danych/guru wydajności tam.SQL Server Datetime vs Int key performance

Jeśli dysponujesz bazą danych, która ma na celu śledzenie danych finansowych za fiskalne okresy roku, czy jest lepsza/bardziej wydajna/bardziej przejrzysta, aby wykonać wyszukiwanie typu daterange, takie jak PaymentDate Between X i Y, czy też lepiej jest zachować intubację? tabela z kluczem i zdefiniowanymi w nim okresami obrachunkowymi, a następnie oznaczyć tabelę płatności datą płatności i tym kluczem, a zatem klauzula where oznacza wartość FiscalPeriodID = X?

Jestem pewien, że dla mniejszych zestawów danych nie ma znaczenia, ale załóżmy, że te dane będą w milionach wierszy.

Odpowiedz

18

Mam do czynienia z magazynami w milionach wierszy na co dzień, i uważamy, że inteligentne klucze daty są drogą do zrobienia. Jest to w formacie RRRRMMDD. Aby znaleźć cały 2008 rok, wystarczy:

select 
    * 
from 
    gl 
where 
    postdate between 20080101 and 20081231 

Dzięki indeksowanej kolumnie jest fenomenalnie szybki, nawet na miliard wierszy. Wskazuje to również na tabelę dat, dzięki czemu możemy uzyskać informacje o dniach tygodnia, nazwach miesięcy lub innych informacjach o datach, które mamy z danym połączeniem.

Oczywiście, te magazyny są zwykle budowane w celu obsługi kostek SSAS (baz danych OLAP), a zatem tabela daty staje się naszym wymiarem daty. O wiele szybciej jest dołączyć do int niż do datetime.

+0

HRM tak, że teraz mogę wziąć to, co napisałeś i badań wydaje się, że jest to dość standardowe rozwiązanie, szczególnie w kostkach. – Eric

+1

Co z częścią "time"? Co się stanie, jeśli będę musiał również przechowywać czas? Czy dobrze jest używać osobnego pola na czas, a także przechowywać go jako intergera i w razie potrzeby dokonać konwersji? – Mahmoodvcs

+1

David Stein napisał artykuł na ten temat. Mówi, że pole daty ma lepszą wydajność w SQL 2008. url: [http://www.made2mentor.com/2011/05/date-vs-integer-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

W przypadku dużych zbiorów danych finanso- wych powstają "kostki danych".

Zasadniczo odnosi się to do procesu generowania raportów potrzebnych dla każdego okresu, historycznie, więc nie trzeba wykonywać tych klauzul, wystarczy przeglądać dane dla tego okresu.

Więc to nie ma znaczenia. Przechowuj go jednak i zaimplementuj historyczną bazę danych, która będzie bardziej wydajna w przypadku długoterminowego raportowania.

Wybrałbym datę zapisaną bezpośrednio przy wejściu.

0

Jeśli możesz użyć smalldatetime, jest to ten sam rozmiar co liczba całkowita - oba 4 bajty. A pod maską datatypes datetime są liczbami całkowitymi.

Pierwsze 2 bajty smalldatetime są podobne do liczby dni, które upłynęły od może 1/1/1900, a drugie 2 bajty są podobne do liczby sekund, które upłynęły od północy. (To może nie być dokładne, ale masz rację.) Więc te typy danych są bardzo wydajne.

Myślę, że klauzula where wykonana względem pola smalldatetime będzie w porządku.

2

również pod uwagę to, co jest w istocie termin część rzeczywistej datetime lub smalldatetime dziedzinie ... 4-bajtowy całkowitą reprezentującą liczbę dni od 1 stycznia 1900.

To może być oddane do rzeczywistej datetime niejawnie, bardzo szybko (ponieważ jest to dokładnie taka sama wartość jak pierwsze cztery bajty 8-bajtowej wartości DateTime)

można również użyć jej w klauzulach Where względem rzeczywistych wartości datetime, ponieważ silnik SQL Server niejawnie konwertuje jeden do drugiego iz powrotem.

Plus, każdy possile wartość 32-bitowy (4-bajtowy) liczb całkowitych jest prawidłowy datetime (Midnight) dla wewnętrznego serwera SQL Datetime typu danych