nvarchar (max) vs NText

Quais são as vantagens e desvantagens de usar os tipos de dados nvarchar(max)vs. NTextno SQL Server? Como não preciso de compatibilidade com versões anteriores, nvarchar(max)não há problema em não ser suportado em versões mais antigas do SQL Server.

Editar: Aparentemente, a pergunta também se aplica a TEXTe IMAGEcontra varchar(max)e varbinary(max), para aqueles que pesquisam esses tipos de dados posteriormente.

As vantagens são que você pode usar funções como LENe por LEFTdiante nvarchar(max)e não pode fazer isso contra ntexte text. Também é mais fácil trabalhar do nvarchar(max)que textonde você tinha que usar WRITETEXTe UPDATETEXT.

Além disso, text, ntext, etc, estão a ser preterido ( http://msdn.microsoft.com/en-us/library/ms187993.aspx )

VARCHAR(MAX)é grande o suficiente para acomodar o TEXTcampo. TEXT, NTEXTE IMAGEtipos de dados do SQL Server 2000 será depreciado em versão futura do SQL Server, SQL Server 2005 oferece compatibilidade com os tipos de dados, mas é recomendado o uso de novos tipos de dados que são VARCHAR(MAX), NVARCHAR(MAX)e VARBINARY(MAX).

ntextsempre armazenará seus dados em uma página separada do banco de dados, enquanto nvarchar(max)tentará armazenar os dados no próprio registro do banco de dados.

Então, nvarchar(max)é um pouco mais rápido (se você tiver um texto menor que 8 kB). Notei também que o tamanho do banco de dados aumentará um pouco mais devagar, isso também é bom.

Vá nvarchar(max).

nvarchar(max)é o que você deseja usar. A maior vantagem é que você pode usar todas as funções de seqüência de caracteres T-SQL nesse tipo de dados. Isso não é possível com ntext. Não estou ciente de nenhuma desvantagem real.

Você aparentemente deveria usar nvarchar(max):

MSDN

A maior desvantagem de Text(junto com NTexte Image) é que ele será removido em uma versão futura do SQL Server, como na documentação . Isso tornará seu esquema mais difícil de atualizar quando a versão do SQL Server for lançada.

Queria adicionar minha experiência com a conversão. Eu tinha muitos textcampos no código Linq2SQL antigo. Isso permitiu que as textcolunas presentes nos índices fossem reconstruídas ONLINE .

Primeiro, eu conheço os benefícios há anos, mas sempre presumi que a conversão significaria algumas consultas longas e assustadoras, nas quais o SQL Server teria que reconstruir a tabela e copiar tudo, derrubando meus sites e aumentando a frequência cardíaca.

Eu também estava preocupado que o Linq2SQL pudesse causar erros se estivesse realizando algum tipo de verificação do tipo de coluna.

É um prazer informar que os comandos ALTER retornaram INSTANTANEAMENTE - portanto, eles definitivamente estão apenas alterando os metadados da tabela. Pode haver algum trabalho offline acontecendo para trazer <8000 caracteres de volta à tabela, mas o comando ALTER foi instantâneo.

Executei o seguinte para encontrar todas as colunas que precisam de conversão:

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

Isso me deu uma boa lista de consultas, que eu apenas selecionei e copiei para uma nova janela. Como eu disse - executar isso foi instantâneo.

O Linq2SQL é bastante antigo - ele usa um designer para o qual você arrasta tabelas. A situação pode ser mais complexa para o Código EF primeiro, mas ainda não o resolvi.

Quero acrescentar que você pode usar a cláusula .WRITE para atualizações parciais ou completas e o alto desempenho anexado avarchar(max)/nvarchar(max) tipos de dados.

Aqui você pode encontrar um exemplo completo da .WRITEcláusula using .