Nou, ik heb het op de proef gesteld, en het plaatsen van een geclusterde index op de twee "chunk-defining" kolommen verhoogt de prestaties van mijn tabel.
Het invoegen van een chunk gaat nu relatief snel in vergelijking met de situatie waarin ik een geclusterde IDENTITY-sleutel had, en ongeveer net zo snel als toen ik geen geclusterde index had. Het verwijderen van een chunk gaat sneller dan met of zonder geclusterde index.
Ik denk dat het feit dat alle records die ik wil verwijderen of invoegen, gegarandeerd allemaal samen op een bepaald deel van de harde schijf staan, de tabellen sneller maakt - het lijkt me logisch.
Bijwerken :Na een jaar ervaring met dit ontwerp kan ik zeggen dat om deze aanpak te laten werken, het noodzakelijk is om regelmatig alle indexen opnieuw op te bouwen (we doen het een keer per week). Anders raken de indexen zeer snel gefragmenteerd en gaan de prestaties verloren. Desalniettemin zitten we in een proces van migratie naar een nieuw database-ontwerp met gepartitioneerde tabellen, wat in principe in alle opzichten beter is - behalve de kosten van de Enterprise Server-licentie, maar dat zijn we nu al vergeten. Dat heb ik tenminste.