Impact de la vitesse d'utilisation de varchar dans SQL Server 2008

Autrefois, utiliser varcharover charétait un gros non non, car le varcharétait stocké sur une page différente de celle du reste de la ligne. Est-ce toujours le cas aujourd'hui avec SQL Server 2008? Vais-je voir un gain de mémoire / performances en changeant 1 varchar(5)à 3 colonnes en char(5)colonnes sur une table avec

a) dites 2.000.000 de lignes b) si l'une des varcharcolonnes fait partie des index / des clés primaires

Vous confondez text / varchar (max) (types LOB) avec varchar (n) / char (n)

• Les types de LOB seront toujours stockés en ligne / hors ligne en fonction de la taille, de la MISE À JOUR, de l' option sp_table, etc.
• varchar (n) / char (n) ont toujours été "en ligne"

Sinon, si vous utilisez char (1000) et non varchar (1000) et que la longueur moyenne des données est, disons, 42 c'est une mauvaise conception et beaucoup d'espace gaspillé.

Il est difficile de vous parler de gains de performances ou de hits spécifiques sans en savoir plus sur votre schéma, mais en général, vous voulez définir le dataype pour correspondre à vos données. Si vous avez besoin d'une largeur fixe (par exemple, vous savez que vous aurez toujours cinq caractères), vous devez utiliser char (5). Si vous avez une quantité variable de données, vous devez utiliser varchar (5).

Pour SQL, plus vous pouvez insérer de données sur une page, meilleures sont vos performances.

Pour autant que je sache, SQL Server n'a jamais stocké de types de données varchar ou nvarchar hors ligne. Le texte et NText sont différents. Il y a quelques bits supplémentaires qui sont stockés pour une colonne de largeur variable mais c'est à peu près tout.