Cela dépend vraiment de la quantité de données qui change. Disons que ce tableau comporte 20 colonnes. Et vous avez également 5 index - chacun sur un diff. colonne.
Maintenant, si les valeurs des 20 colonnes changent OU même si les données de 5 colonnes changent et que ces 5 colonnes sont toutes indexées, il vaut mieux "supprimer et insérer". Mais si seulement 2 colonnes changent et permettent de dire que celles-ci ne font partie d'aucun index non clusterisé, alors vous feriez mieux de "mettre à jour" les enregistrements car dans ce cas, seul l'index clusterisé sera mis à jour (et les index n'auront pas à être mis à jour).
Sur des recherches plus poussées, j'ai trouvé que le commentaire ci-dessus par moi est en quelque sorte redondant car SQL Server dispose en interne de 2 mécanismes distincts pour effectuer une MISE À JOUR. - Une "mise à jour sur place" (c'est-à-dire en changeant une valeur de colonne en une nouvelle dans la ligne d'origine) ou comme une "MISE À JOUR non sur place" (SUPPRIMER suivie d'une INSÉRER).
Les mises à jour sur place sont la règle et sont effectuées si possible. Ici, les lignes restent exactement au même emplacement sur la même page dans la même étendue. Seuls les octets concernés sont modifiés. Le tlog n'a qu'un seul enregistrement (à condition qu'il n'y ait pas de déclencheurs de mise à jour). Les mises à jour se produisent sur place si un segment de mémoire est mis à jour (et qu'il y a suffisamment d'espace sur la page). Les mises à jour se produisent également si la clé de clustering change mais que la ligne n'a pas du tout besoin de se déplacer.
Par exemple: si vous avez un index clusterisé sur le nom de famille et que vous avez les noms: Able, Baker, Charlie Maintenant, vous voulez mettre à jour Baker vers Becker. Aucune ligne ne doit être déplacée. Cela peut donc prendre place. Alors que si vous devez mettre à jour Able vers Kumar, les lignes devront être décalées (même si elles seront sur la même page). Dans ce cas, SQL Server effectuera une DELETE suivie d'une INSERT.
Compte tenu de ce qui précède, je vous suggère de faire une MISE À JOUR normale et de laisser SQL Server trouver la meilleure façon de le faire en interne.
Pour plus de détails sur les internes «MISE À JOUR» ou d'ailleurs sur les internes liés à SQL Server, consultez le livre de Kalen Delaney, Paul Randal et al. - SQL Server 2008 Internals .