Měli byste ROZHODNĚ zavést náhradní INT IDENTITY() primární klíč!!INT vám již dává potenciálně až 2 miliardy řádků - není to málo?
Tento primární klíč / seskupený klíč na SQL Server bude mít velikost až 64 bajtů (namísto 4, pro INT) – díky čemuž bude váš seskupený index A všechen váš neseskupený index nafouklý k nepoznání. Celý shlukovací klíč (všech vašich 8 sloupců) bude zahrnut na každé stránce každého jednotlivého neshlukovaného indexu v této tabulce – jistě se plýtvá spoustou a spoustou místa.
Takže v jakékoli dané indexové tabulce byste měli až 16krát více položek s náhradním seskupeným klíčem INT – to znamená mnohem méně I/O, mnohem méně času stráveného čtením indexových stránek.
A jen si představte, že se pokoušíte vytvořit vztah cizího klíče k této tabulce... každá podřízená tabulka by musela mít všech 8 sloupců vašeho primárního klíče jako sloupce cizího klíče a uveďte všech 8 sloupců v každém spojení – jaká noční můra!!
Při 78 milionech řádků vám i pouhá změna klastrovacího klíče na INT IDENTITY ušetří až 60 bajtů na řádek – to samo o sobě by znamenalo až 4 GB místa na disku (a využití RAM na vašem serveru). A to ještě ani nezačíná počítat úspory na neseskupených indexech......
A samozřejmě ano, také bych změnil VARCHAR(10) na INT nebo BIGINT - pokud je to číslo, udělejte typ pole numerický - nemá smysl ho nechávat na VARCHAR(10), opravdu. Ale to samo o sobě nezpůsobí velký rozdíl, pokud jde o rychlost nebo výkon – jen to výrazně usnadňuje práci s daty (nemusíte se vždy obracet na číselné typy, když například porovnáváte hodnoty a tak dále).
Marc