nvarchar (max) vs NText
Quels sont les avantages et les inconvénients de l'utilisation des types de données nvarchar(max) vs. NText dans SQL Server? Je n'ai pas besoin de compatibilité ascendante, il est donc normal que nvarchar(max) ne soit pas pris en charge dans les anciennes versions de SQL Server.
Edit: Apparemment, la question s'applique également à TEXT et IMAGE par rapport à varchar(max) et varbinary(max), pour ceux qui recherchent ces types de données ultérieurement.
Les avantages sont que vous pouvez utiliser des fonctions telles que LEN et LEFT sur nvarchar(max) et vous ne pouvez pas le faire contre ntext et text. Il est également plus facile de travailler avec nvarchar(max) que text où vous deviez utiliser WRITETEXT et UPDATETEXT.
De plus, text, ntext, etc., sont obsolètes ( http://msdn.Microsoft.com/en-us/library/ms187993.aspx )
VARCHAR(MAX) est assez grand pour contenir le champ TEXT. TEXT, NTEXT et IMAGE les types de données de SQL Server 2000 seront obsolètes dans les versions futures de SQL Server. SQL Server 2005 offre une compatibilité ascendante avec les types de données, mais il est recommandé d'utiliser de nouvelles données. types qui sont VARCHAR(MAX), NVARCHAR(MAX) et VARBINARY(MAX).
ntext stockera toujours ses données dans une page de base de données séparée, alors que nvarchar(max) essaiera de stocker les données dans l'enregistrement de base de données lui-même.
Donc, nvarchar(max) est un peu plus rapide (si vous avez un texte plus petit que 8 Ko). J'ai également remarqué que la taille de la base de données augmentera légèrement plus lentement, ce qui est également une bonne chose.
Allez nvarchar(max).
nvarchar(max) est ce que vous voulez utiliser. Le principal avantage est que vous pouvez utiliser toutes les fonctions de chaîne T-SQL sur ce type de données. Ceci n'est pas possible avec ntext. Je ne suis au courant d'aucun inconvénient réel.
Le principal inconvénient de Text (avec NText et Image) est qu'il sera supprimé dans une future version de SQL Server, comme par la documentation . Cela rendra effectivement votre schéma plus difficile à mettre à niveau lorsque cette version de SQL Server sera publiée.
Vous devriez apparemment utiliser nvarchar(max):
Je voulais ajouter mon expérience avec la conversion. J'avais beaucoup de champs text dans l'ancien code Linq2SQL. Cela permettait aux colonnes text présentes dans les index d'être reconstruit ONLINE .
Tout d'abord, je connais les avantages depuis des années, mais j'ai toujours supposé que la conversion impliquerait de longues requêtes effrayantes dans le cadre desquelles SQL Server serait obligé de reconstruire le tableau et de tout copier, ce qui aurait pour effet de faire baisser mes sites Web et d'élever mon cœur.
Je craignais également que Linq2SQL puisse provoquer des erreurs s’il effectuait une sorte de vérification du type de colonne.
Heureux de signaler cependant que les commandes ALTER ont été renvoyées INSTANTANEMENT - elles ne modifient donc que les métadonnées de la table. Il se peut que des travaux hors ligne soient en cours pour ramener <8 000 caractères de données dans la table, mais la commande ALTER a été instantanée.
J'ai exécuté ce qui suit pour trouver toutes les colonnes nécessitant une conversion:
SELECT concat('ALTER TABLE dbo.[', table_name, '] ALTER COLUMN [', column_name, '] VARCHAR(MAX)'), table_name, column_name
FROM information_schema.columns where data_type = 'TEXT' order by table_name, column_name
SELECT concat('ALTER TABLE dbo.[', table_name, '] ALTER COLUMN [', column_name, '] NVARCHAR(MAX)'), table_name, column_name
FROM information_schema.columns where data_type = 'NTEXT' order by table_name, column_name
Cela m'a donné une belle liste de requêtes, que je viens de sélectionner et de copier dans une nouvelle fenêtre. Comme je l'ai dit - cela a été instantané.
Linq2SQL est assez ancien - il utilise un concepteur sur lequel vous faites glisser des tables. La situation est peut-être plus complexe pour EF Code d’abord, mais je ne l’ai pas encore abordée.