Il y a peu d'implications sur les performances, rowversion est juste un nouveau nom pour l'ancien type de données timestamp. Votre base de données devra donc stocker le champ binaire supplémentaire. Vos performances souffriront beaucoup plus lorsque vous essaierez de faire des requêtes sur ces données telles que :
SELECT *
FROM MyTable
WHERE rowVersion > @rowVersion
C'est le moyen courant qui peut être utilisé pour obtenir la liste des éléments mis à jour depuis la dernière @rowVersion. Cela semble bien et fonctionnera parfaitement pour une table avec, par exemple, 10 000 lignes. Mais lorsque vous atteignez 1 million de lignes, vous découvrirez rapidement qu'il a toujours effectué une analyse de table et que votre baisse de performances est due au fait que votre table ne tient plus entièrement dans la RAM du serveur.
C'est le problème courant rencontré avec le rowVersion colonne, elle n'est pas indexée comme par magie. De plus, lorsque vous indexez une colonne rowVersion, vous devez accepter que l'index deviendra souvent très fragmenté au fil du temps, car les nouvelles valeurs mises à jour seront toujours au bas de l'index, laissant des espaces dans l'index lorsque vous mettez à jour les éléments existants. .
Modifier :si vous n'allez pas utiliser le rowVersion champ pour vérifier les éléments mis à jour et à la place, vous allez l'utiliser pour la cohérence afin de vous assurer que l'enregistrement n'est pas mis à jour depuis votre dernière lecture, alors cela sera une utilisation parfaitement acceptable et n'aura pas d'impact.
UPDATE MyTable SET MyField = ' @myField
WHERE Key = @key AND rowVersion = @rowVersion
