none
nvarchar(max) RRS feed

Todas as Respostas

  • Olá Tatiane,

     

    Sempre que possível, tente ser mais específica em sua dúvida. Há muito o que dizer sobre o NVARCHAR(MAX) e apenas perguntar qual sua função pode significar uma simples resposta bem como dezenas de post.

     

    Tão simples quanto a sua pergunta, será a minha resposta. O tipo NVARCHAR(MAX) serve para armazenar dados maiores que 8.000 caractéres (podem chegar até 2GB por registro) e fornecer as funcionalidades do tipo NVARCHAR como utilizar funções do tipo LEFT, RIGHT, SUBSTRING, etc.

     

    Esse tipo de dados foi colocado no 2005 como substituição ao TEXT (o TEXT não dava pra utilizar em vários cenários).

     

    [ ]s,

     

    Gustavo

     

    quinta-feira, 16 de outubro de 2008 16:41
  • Boa tarde Tatiane apenas completando a informação do nosso amigo:

     

    O NVARCHAR difere do VARCHAR por permitir UNICODE, se seu banco de dados não necessitar de suporte a línguas asiáticas por exeplo prefira VARCHAR, visto que o tipo NVARCHAR consome DUAS VEZES mais espçao que o VARCHAR, esta regra também se aplica a NCHAR e CHAR

     

     

     

     

     

    Espero ter ajudado

     

    quinta-feira, 16 de outubro de 2008 17:28
  •  Anderson.dpa wrote:

    ... O NVARCHAR difere do VARCHAR por permitir UNICODE, se seu banco de dados não necessitar de suporte a línguas asiáticas por exeplo prefira VARCHAR ... 

     

    Olá Anderson,

     

    Sua resposta está certíssima, mas tenho minhas dúvidas quanto a afirmação de que devemos dar preferência à VARCHAR quando não precisamos de suporte à linguas asiáticas.

     

    Uma vez que o banco de dados será acessado, de alguma forma, por outras ferramentas que provavelmente utilizam Unicode internamente para representar strings, você acha que ainda faz algum sentido utilizar VARCHAR hoje em dia?

     

    Acredito que, em 90% dos casos, devemos dar preferência à NVARCHAR, NCHAR, etc... Não por causa do suporte às línguas asiáticas, mas para evitar a conversão constante de dados entre banco de dados (VARCHAR) e software (UNICODE).

     

    Os outros 10% seriam exceções devido à restrições... Ambientes com storage limitado, tabelas extremamente gigantes, etc...

     

    O que você acha?

     

    Abraços,

    Caio Proiete




    Caio Proiete
    http://www.caioproiete.com
    quinta-feira, 16 de outubro de 2008 18:22
  • Oi Caio,

     

    Não sei bem se evitar as conversões entre VARCHAR e software Unicode seria um objetivo a ser perseguido (pelo menos nunca vi qualquer tipo de recomendação para que isso fosse feito). Se utilizarmos NVARCHAR e NCHAR estaremos aumentando o tamanho armazenado ocupando o dobro do tamanho para tipos textuais. Limitação de espaço nesse sentido não costuma ser um problema (normalmente temos problemas de espaço por conta de grandes quantidades de registros, mas não por conta de um tipo de dados).

     

    Minha preocupação é que trocar o tipo de dados para Unicode sem a real necessidade fará com que eles ocupem o dobro do tamanho e com isso menos registros caberão nas páginas de dados e de índices. Se menos registros cabem nas páginas de dados e de índice, maior será o esforço para a recuperação de dados, pois, mais páginas deverão ser lidas. Haverá também um maior consumo de memória para hospedar esses dados durante a recuperação do disco e gravação nas páginas em memória.

     

    A julgar pelo meu raciocínio e pela ausência de recomendações nesse sentido, penso que não seria um bom negócio. Em todo caso, existe alguma recomendação para utilizar os tipos Unicode como solução padrão por conta das conversões ?

     

    [ ]s,

     

    Gustavo

    quinta-feira, 16 de outubro de 2008 18:33
  • Boa tarde amigos, concordo com ambas posições, sem dúvida a escolha do tipo de dado vai depender do cenário. De forma minimalista prefiro utilizar VARCHAR a NVARCHAR.

     

     

     

    Abraço a todos

    quinta-feira, 16 de outubro de 2008 19:47
  •  Gustavo Maia Aguiar wrote:

    Minha preocupação é que trocar o tipo de dados para Unicode sem a real necessidade fará com que eles ocupem o dobro do tamanho e com isso menos registros caberão nas páginas de dados e de índices. Se menos registros cabem nas páginas de dados e de índice, maior será o esforço para a recuperação de dados, pois, mais páginas deverão ser lidas. Haverá também um maior consumo de memória para hospedar esses dados durante a recuperação do disco e gravação nas páginas em memória.

     

    Good point!

     

    Não lembro de ver nenhuma recomendação formal da Microsoft, mas lembro de um projeto que trabalhei há alguns anos (ainda SQL Server 2000), em uma aplicação que trabalhava essencialmente com manipulação de strings que vinham de uma tabela cheia de campos TEXT, e a mudança para NTEXT melhorou a performance em mais de 30% naquela época.

     

    Seria interessante medir esse o ganho de performance na conversão X perda de performance na recuperação dos dados.

     

    Abraços,
    Caio Proiete




    Caio Proiete
    http://www.caioproiete.com
    quinta-feira, 16 de outubro de 2008 23:42
  • Oi Caio,

     

    Achei a sua preocupação bem coerente. Realmente os CASTs internos de um padrão não Unicode em relação a um Unicode poderiam ter impacto em desempenho (quando vi sua colocação percebi que nunca tinha me atentado para isso). Se observarmos algumas implementações da Microsoft, veremos que algumas vezes, aparecem implementações Unicode (o CustomerID é do Northwind é NCHAR e os exemplos baseados no método Value do XML também são NVARCHAR), mas é que nunca tinha visto qualquer recomendação nesse sentido.

     

    A julgar pela possibilidade (muito grande por sinal) de termos campos textuais compondo chaves primárias e índices (UF, CPF, Sobrenome, etc), a influência do Unicode seria negativa, mas talvez seja mais um trade off (Recuperação vs Conversão).

     

    Acredito que no seu projeto, essa mudança tenha melhorado o desempenho por conta da situação do campo TEXT. Campos TEXT não são indexados, não são comparados em uma cláusula WHERE e nem utilizados em colunas para JOINs, então a julgar pelo aspecto indexação, talvez não faça diferença em retornar um TEXT ou um NTEXT. Pode ser que a evitar a conversão tenha valido mais a pena.

     

    Se achar alguma referência sobre esse assunto não deixe de postar...

     

    [ ]s,

     

    Gustavo

    sexta-feira, 17 de outubro de 2008 02:03