2011-12-07 9 views
6

Chcę obsłużyć wymiar daty w bazie danych MySQL. (Jestem nowicjuszem w świecie DW)Użycie pola DATE jako klucza podstawowego wymiaru daty przy użyciu MySQL

Zrobiłem kilka wyszukiwań z google i widziałem wiele struktur tabeli (większość) wymiaru daty, gdzie klucz podstawowy jest prosty UNSIGNED INTEGER.

Dlaczego nie używać pola DATE jako klucza podstawowego, ponieważ w przypadku MySQL jest to 3 bajty VS 4 Bytes dla INTEGER?

Ex:

CREATE TABLE dimDate 
id INTEGER UNSIGNED NOT NULL PRIMARY AUTOI_NCREMENT, 
date DATE NOT NULL, 
dayOfWeek 
... 

VS

CREATE TABLE dimDate 
date DATE NOT NULL PRIMARY, 
dayOfWeek 
... 
+2

Nie spodziewasz się mieć wielu rekordów na tę samą datę? – Mat

+1

Nie, będę oczekiwał wielu rekordów dla tej samej daty w mojej tabeli faktów, a nie tabeli wymiarów. – nemenems

+0

Kimball mówi, że każdy wymiar pk powinien być surogatem. –

Odpowiedz

6

Jeśli masz tabelę z kolumny, która jest date typu i gdzie nie dwa wiersze nigdy nie będzie miał tego samego dnia, a następnie można z pewnością użyj tej kolumny jako PRIMARY KEY.

Widzisz wiele przykładów, w których klucz podstawowy jest prosty UNSIGNED INTEGER, ponieważ istnieje wiele przypadków, w których nie ma idealnego kandydata na klucz podstawowy. Opcja AUTO_INCREMENT umożliwia automatyczne wypełnianie tej kolumny przez bazę danych (i unikatowość) podczas wstawiania.

14

Wymiar daty jest szczególny - posiadanie daty (2011-12-07) lub daty związanej z datą (20111207) dla klucza podstawowego jest w rzeczywistości preferowane. Pozwala to na ładną partycjonowanie (według daty) tabel faktów.

Dla innych typów wymiarów zalecane są klucze zastępcze (całkowite).

jako matrycy, każdy wymiar ma zwykle wpisy dla unknown, not entered, error, ... które często są dopasowane klucze 0, -1, -2, ...

ze względu na to, że jest bardziej powszechne, aby znaleźć całkowitą formacie daty (20111207) jako klucz podstawowy, zamiast daty - trochę nieładnie przedstawiają unknown, not entered, error, ... z kluczem typu daty.

Powiązane problemy