Powinieneś ZDECYDOWANIE wprowadź zastępczy INT IDENTITY() klucz podstawowy!!INT daje już potencjalnie do 2 miliardów wierszy - czy to nie wystarczy?
Ten klucz podstawowy/klucz klastrowy w SQL Server będzie miał rozmiar do 64 bajtów (zamiast 4 dla INT) — co spowoduje, że indeks klastrowy ORAZ cały indeks nieklastrowy będzie rozdęty nie do poznania. Cały klucz klastrowania (wszystkie 8 kolumn) zostanie uwzględniony na każdej stronie każdego nieklastrowanego indeksu w tej tabeli - na pewno marnując mnóstwo miejsca.
Tak więc w dowolnej tabeli indeksu będziesz mieć do 16 razy więcej wpisów z zastępczym kluczem klastrowym INT - oznacza to o wiele mniej operacji we/wy, o wiele mniej czasu straconego na czytanie stron indeksu.
I wyobraź sobie, że próbujesz ustanowić relację klucza obcego z tą tabelą... każda tabela podrzędna musiałaby mieć wszystkie 8 kolumn klucza podstawowego jako kolumny klucza obcego i określ wszystkie 8 kolumn w każdym sprzężeniu - co za koszmar!
Przy 78 milionach wierszy, nawet zmiana klucza klastrowania na INT IDENTITY pozwoli zaoszczędzić do 60 bajtów na wiersz – samo to daje do 4 GB miejsca na dysku (i wykorzystania pamięci RAM na serwerze). A to nawet nie zaczyna obliczać oszczędności na indeksach nieklastrowanych.......
I oczywiście tak, zmieniłbym również VARCHAR(10) na INT lub BIGINT - jeśli jest to liczba, ustaw typ pola na numeryczny - nie ma sensu zostawiać go w VARCHAR(10), naprawdę. Ale samo to nie zrobi ogromnej różnicy pod względem szybkości lub wydajności - po prostu znacznie ułatwia pracę z danymi (nie musisz zawsze odwoływać się do typów numerycznych, np. porównując wartości i tak dalej).
Marek
