Трябва да ОПРЕДЕЛЕНО въведете сурогат INT IDENTITY() първичен ключ!!INT вече ви дава потенциално до 2 милиарда реда - това не е ли достатъчно??
Този първичен ключ / клъстерен ключ на SQL Server ще бъде с размер до 64 байта (вместо 4, за INT) - което ще направи вашия клъстерен индекс И целият ви неклъстерен индекс да се раздуе до неузнаваемост. Целият ключ за клъстериране (всичките ви 8 колони) ще бъде включен на всяка отделна страница от всеки един неклъстериран индекс в тази таблица - загуба на много, много място със сигурност.
Така че във всяка дадена индексна таблица бихте имали до 16 пъти повече записи със сурогатен INT клъстериран ключ - това означава много по-малко I/O, много по-малко време, загубено за четене на индексни страници.
И само си представете, че се опитвате да установите връзка с външен ключ към тази таблица... всяка дъщерна таблица ще трябва да има всичките 8 колони на вашия първичен ключ като колони за външен ключ и посочете всичките 8 колони във всяко съединение - какъв кошмар!!
При 78 милиона реда, дори само промяната на ключа за клъстериране на INT IDENTITY ще ви спести до 60 байта на ред - само това ще излезе до 4 GB дисково пространство (и използване на RAM във вашия сървър). И това дори не е началото за изчисляване на спестяванията от неклъстърираните индекси.......
И разбира се, да, бих променил и VARCHAR(10) на INT или BIGINT - ако е число, направете типа на полето числов - няма смисъл да го оставяте на VARCHAR(10), наистина. Но това само по себе си няма да направи огромна разлика по отношение на скоростта или производителността - то просто прави работата с данните много по-лесна (не е необходимо винаги да избирате числови типове, когато например сравнявате стойности и т.н.).
Марк
