nvarchar (max) vs NText
Quels sont les avantages et les inconvénients de l'utilisation des types de données nvarchar(max) par rapport à NText dans SQL Server? Je n'ai pas besoin de rétrocompatibilité, il est donc bon 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 vs. varchar(max) et varbinary(max), pour ceux qui recherchent ces types de données plus tard.
8 réponses
Les avantages sont que vous pouvez utiliser des fonctions comme LEN et LEFT sur nvarchar(max) et vous ne pouvez pas le faire à l'encontre de ntext et text. Il est également plus facile de travailler avec nvarchar(max) que text où vous avez eu à utiliser WRITETEXT et UPDATETEXT.
Aussi, text, ntext, etc., sont obsolètes ( http://msdn.microsoft.com/en-us/library/ms187993.aspx )
VARCHAR(MAX) est assez grand pour accueillir TEXT champ. TEXT, NTEXT et IMAGE les types de données de SQL Server 2000 seront obsolètes dans la future version de SQL Server, SQL Server 2005 fournit une compatibilité descendante aux types de données, mais il est recommandé d'utiliser de nouveaux types de données 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, tandis que nvarchar(max) essayera 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, c'est aussi bon.
Allez nvarchar(max).
nvarchar(max) est ce que vous voulez utiliser. Le plus grand avantage est que vous pouvez utiliser toutes les fonctions de chaîne T-SQL sur ce type de données. Ce n'est pas possible avec ntext. Je ne suis pas au courant des inconvénients réels.
, Le plus grand inconvénient de Text (avec NText et Image), c'est qu'il sera supprimée dans une future version de SQL Server, comme par la documentation. Cela rendra votre schéma plus difficile à mettre à niveau lorsque cette version de SQL Server sera publiée.
Voulait ajouter mon expérience avec la conversion. J'avais beaucoup de champs text dans l'ancien code Linq2SQL. Cela devait permettre aux text colonnes présentes dans les index d'être reconstruites en ligne .
D'abord, je connais les avantages depuis des années, mais j'ai toujours supposé que la conversion signifierait de longues requêtes effrayantes où SQL Server devrait reconstruire la table et tout copier, faire tomber mes sites Web et élever mon rythme cardiaque.
J'étais également préoccupé par le fait que le Linq2SQL pourrait provoquer des erreurs si elle faisait une sorte de vérification du type de colonne.
Heureux de signaler cependant, que les commandes ALTER sont retournées instantanément-donc elles ne changent définitivement que les métadonnées de la table. Il peut y avoir un travail hors ligne qui se passe pour ramener
J'ai couru 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 un nouvelle fenêtre. Comme je l'ai dit - courir c'était instantané.
Linq2SQL est assez ancien - il utilise un concepteur sur lequel vous faites glisser des tables. La situation peut être plus complexe pour le code EF d'abord, mais je ne l'ai pas encore abordé.