Je moet DEFINITIEF introduceer een surrogaat INT IDENTITY() primaire sleutel!!INT geeft je al potentieel tot 2 miljard rijen - is dat niet genoeg??
Deze primaire sleutel / geclusterde sleutel op SQL Server zal maximaal 64 bytes groot zijn (in plaats van 4, voor een INT) - waardoor uw geclusterde index EN al uw niet-geclusterde index onherkenbaar opgeblazen wordt. De hele clustersleutel (al je 8 kolommen) zal worden opgenomen op elke afzonderlijke pagina van elke afzonderlijke niet-geclusterde index op die tabel - zeker veel en veel ruimte verspillend.
Dus op een gegeven indextabel zou je tot 16 keer meer items hebben met een surrogaat INT geclusterde sleutel - dat betekent veel minder I/O, veel minder tijd verspild aan het lezen van indexpagina's.
En stel je eens voor dat je probeert een refererende-sleutelrelatie met die tabel tot stand te brengen.... elke onderliggende tabel zou alle 8 kolommen moeten hebben van uw primaire sleutel als externe sleutelkolommen, en specificeer alle 8 kolommen in elke join - wat een nachtmerrie!!
Bij 78 miljoen rijen, zal zelfs het veranderen van de clustersleutel naar INT IDENTITY u tot 60 bytes per rij besparen - dat alleen al zou uitkomen op maximaal 4 GByte schijfruimte (en RAM-gebruik op uw server). En dat is nog niet eens begonnen met het berekenen van de besparingen op de niet-geclusterde indices.......
En natuurlijk, ja, ik zou ook de VARCHAR (10) veranderen in INT of BIGINT - als het een getal is, maak het veldtype dan numeriek - het heeft geen zin om het op VARCHAR (10) te laten, eigenlijk. Maar dat alleen zal geen enorm verschil maken in termen van snelheid of prestaties - het maakt het werken met de gegevens alleen maar veel gemakkelijker (hoeft niet altijd naar numerieke typen te gaan bij het vergelijken van waarden, enzovoort).
Marc