qual melhor null ou em branco ?

[andreia_sp 1]

Performaticamente qual o melhor para um campo, null ou em branco ?

[Motta 645]

Nulo é diferente de branco, nulo é quando a informação não tem valor, branco (ou zero) quando tem.

 

Nulo não soma, nulo não é igual a outro nulo etc.

 

Quanto ao uso vai depender do que se está falando para se definir o "melhor".

 

Numa modelagem ideal não deveria haver nulos pois todos os campos teriam valor, mas o mundo não é ideal ...

 

Quanto a questões de performance creio que a única diferença seria o espaço em disco/memôria.

[@fabiosantosrj 0]

"performaticamente" eu nem sei o que significa essa palavra :)

mas, o que vejo na diferença entre null e vazio é que NULL não existe e VAZIO contém um valor vazio. Ex:

 

- em caso de memória, NULL não é armazenado, não tem endereço fisico. Vazio, tem um endereço de memória armazenado.

- em caso de formulario, voce sabe que o usuario preencheu algo. VAZIO, ou seja deixou em branco. já o NULL significa que não foi utilizado o campo no formulario. tipo, o campo pode aceitar null, mas se os dados vier de um formulario que o usuario nao preencheu eu coloco como vazio. já se o formulario nao exibiu o campo então eu nao gravo nada e deixo o NULL

 

eu não tenho certeza, mas acredito que o vazio ocupe espaço em disco, já o null não.

[andreia_sp 1]

eu sei a diferença entre branco e null, a dúvida é quanto à performance. Obrigada

[eriva_br 7]

eu sei a diferença entre branco e null, a dúvida é quanto à performance. Obrigada

já li (mas não lembro onde) que a busca com NULL fica mais rápida que a busca por '' branco, mas é um valor quase insignificante, creio que a questão de armazenamento como mencionado acima seja mais 'significativa' que em relação a performance

 

cheers!

[Motta 645]

Mais ainda creio que a questão conceitual sobrepõe a performance.

 

Imagine um campo COMPLENTO_DE_ENDERECO, nulo significa que NÂO TEMOS a informação, BRANCO que temos a informação e o endereço em questão não tem COMPLEMENTO.

 

Apenas expliquei a diferença entre nulo e branco pois no questionamento não ficou claro se você sabia ou não.

[fabiano maia franco 1]

Concordo com o Motta. Também prefiro trabalhar o conceito nesse caso. Depois descobri que o desempenho também melhora.

 

O nulo é um tipo especial de dado, um "mapa de bits", que informa que não há nada naquele campo.

 

O problema é que o nulo não é muito bem vindo a todos os bancos de dados, inclusive o Sql Server. Em alguns bancos ele sequer entra em índices, ou seja, você não pode criar um índice a partir de uma coluna que permita entrar com nulo.

 

O nulo requer um tratamento especial por parte do banco de dados porque ele não é de nenhum tipo de dado, ou seja, não dá para colocá-lo na regra geral. Ele é a excessão.

 

Por exemplo, sempre que você faz uma consulta com "Is Null", o banco faz essa consulta de forma diferente de quando você faz algo como "EstadoCivil = 'CASADO'".

 

Exemplificando:

 

- Temos uma tabela de clientes com as colunas "Nome", "Sexo", "EstadoCivil", "Telefone", "Filhos". A coluna "Filhos" admite nulos. Agora analisemos a seguinte consulta:

 

Select * From Clientes Where Sexo = 'F' And EstadoCivil = 'CASADO' And Filhos Is Not Null

 

Queremos buscar todas as mulheres casadas que tenham filhos por questão de enviar uma mala-direta direcionada a esse público alvo.

 

O Sql Server vai processar assim:

 

1º) Sexo = 'F' And EstadoCivil = 'CASADO' (simultaneamente, usando um índice, se houver, senão ele toma a decisão a partir do "optimizer")

2º) Is Not Null (após passar pela primeira fase da consulta)

 

Bem, isso depende inclusive da versão do banco. Era assim lá nos primórdios da versão 2000. De qualquer forma o valor nulo ainda requer atenção especializada que acaba prejudicando o desempenho.

 

Veja aqui: http://msdn.microsoft.com/en-us/library/ms191178.aspx

 

"A table should avoid nullable columns.

 

Tables can have columns defined to allow for null values. A null value indicates that there is no value. Although it can be useful to allow for null values in isolated cases, you should use them sparingly. This is because they require special handling that increases the complexity of data operations. If you have a table with several nullable columns and several of the rows have null values in the columns, you should consider putting these columns in another table linked to the primary table. By storing the data in two separate tables, the primary table can be simple in design and still handle the occasional need for storing this information."

 

Essa página fala sobre a normalização de dados no Sql Server 2008 R2, ou seja, não mudou lá muita coisa esse negócio de nulo, rs.

 

O que eu costumo fazer é criar valores para representar o nulo.

 

Campos varchar eu uso a string vazia ("") para representar o nulo (não confundir string vazia com nulo). Campos data eu coloco a data de 01/01/1900 para representar o valor nulo. Numéricos eu uso o zero como valor padrão e assim por diante.

 

Além disso você ainda pode lançar mão de outras técnicas para melhorar o desempenho.

 

Vamos pegar a tabela acima como exemplo:

 

1) O campo EstadoCivil eu prefiro criá-lo numérico, um TinyInt por exemplo, com valores representando os estados civis, em vez de descrevê-los:

 

0 - Solteiro

1 - Casado

2 - Separado

3 - Divorciado

4 - Viúvo

 

2) O campo sexo eu já prefiro colocar em um campo lógico, mas pode usar o exemplo do EstadoCivil:

 

Verdadeiro = Feminino

Falso = Masculino

 

3) Um campo endereço eu "quebro" em partes, criando tabelas de estados, de cidades, de bairros, de ceps, etc. Por quê? Para poder padronizar a informação, afinal informação sem padronização não serve para muita coisa. Por exemplo, se você tiver um campo "Cidade" aberto em um VarChar( 50 ) e deixar por conta do usuário preenchê-lo (fódéó), ele pode preencher a cidade de São Paulo assim: "São Paulo", "Sao Paulo", "SaoPaulo", "Sampa", "Sao Paulo", "S. Paulo", etc.

 

Certo, agora imagine fazer uma busca pelos clientes na cidade de São Paulo? Complicou, né não?

 

4) Para campos numéricos prefira tipos numéricos mais próximos da quantidade de opções que você prevê que será possível. Por exemplo, no caso do "EstadoCivil", com tão poucas opções, eu não vou armazenar em um campo do tipo inteiro longo, ocupando caríssimos 4 bytes só para essa informação, para cada registro.

 

Assim você ocupa menos espaço em disco, gera menos E/S na gravação/leitura, gera menor tráfego na rede, ocupa menos memória RAM quando o dado é lido para uso e ainda ganha um presente do papai noel por ter sido uma boa menina! :D

 

Uma regra básica é a seguinte: "Dá para tabelar? Então tabela!". Você evita erros de digitação e de educação.

 

Outra: nunca abra uma opção "Outros", rs, o usuário adora essa opção... Não dá trabalho para raciocinar. Se a opção que ele precisa não estiver na sua lista prevista peça a ele qual é a opção e vá lá e inclua. O comum é que exista uma forma de cadastrar a nova opção e delegamos pessoas razoáveis para essa função. Assim você responsabiliza alguém por aquela informação e o "peso da responsabilidade" faz gerar menos erros. Bem, infelizmente nunca acabamos com os erros por completo... :(

 

Você tem que acostumar os olhos a ver o nulo como uma aberração. Se estiver ali é porque há uma razão de vida ou morte, rs, senão não justifica.