Quando usar NULL e quando usar uma string vazia?

Digamos que o registro venha de um formulário para coletar informações de nome e endereço. A linha 2 do endereço normalmente ficará em branco se o usuário não morar em um apartamento. Uma string vazia neste caso é perfeitamente válida. Eu costumo preferir usar NULL para significar que o valor é desconhecido ou não fornecido.

Não acredito que valha a pena se preocupar com a diferença de armazenamento físico na prática. Como administradores de banco de dados, temos peixes muito maiores para fritar!

Eu não sei sobre MySQL e PostgreSQL, mas deixe-me tratar isso um pouco de forma geral.

Existe um DBMS chamado Oracle que não permite escolher seus usuários entre NULL e ''. Isso demonstra claramente que não é necessário distinguir entre ambos. Existem algumas consequências irritantes:

Você define um varchar2 para uma string vazia como esta:

Update mytable set varchar_col = '';

o seguinte leva ao mesmo resultado

Update mytable set varchar_col = NULL;

Mas para selecionar as colunas onde o valor está vazio ou NULL, você deve usar

select * from mytable where varchar_col is NULL;

Usando

select * from mytable where varchar_col = '';

é sintaticamente correto, mas nunca retorna uma linha.

Por outro lado, ao concatenar strings no Oracle. varchars NULL são tratados como strings vazias.

select NULL || 'abc' from DUAL;

rende ab . Outros DBMS retornariam NULL nesses casos.

Quando você deseja expressar explicitamente que um valor é atribuído, você deve usar algo como ' '.

E você precisa se preocupar se aparar não resulta em NULL

select case when ltrim(' ') is null then 'null' else 'not null' end from dual

Sim.

Agora olhando para DBMS onde '' não é idêntico a NULL (por exemplo, SQL-Server)

Trabalhar com '' é geralmente mais fácil e na maioria dos casos não há necessidade prática de distinguir entre ambos. Uma das exceções que conheço é quando sua coluna representa alguma configuração e você não tem padrões vazios para elas. Quando você pode distinguir entre '' e NULL, você pode expressar que sua configuração está vazia e evitar que o padrão se aplique.

Depende do domínio em que você está trabalhando. NULLsignifica ausência de valor (ou seja, não há valor ), enquanto string vazia significa que há um valor de string de comprimento zero.

Por exemplo, digamos que você tenha uma tabela para armazenar os dados de uma pessoa e ela contenha uma Gendercoluna. Você pode salvar os valores como 'Masculino' ou 'Feminino'. Se o usuário puder optar por não fornecer os dados de gênero, você deve salvá-los como NULL(ou seja, o usuário não forneceu o valor) e não uma string vazia (já que não há gênero com valor '').

Uma coisa que vale a pena ter em mente é que, quando você tem um campo que não é obrigatório, mas quaisquer valores presentes devem ser exclusivos, você precisará armazenar valores vazios como NULL. Caso contrário, você só poderá ter uma tupla com um valor vazio nesse campo.

Existem também algumas diferenças com álgebra relacional e valores NULL: NULL != NULL, por exemplo.

Você também pode considerar a crítica de Date a NULL e os problemas de 3VL em SQL e Teoria Relacional (e a crítica de Rubinson à crítica de Date, Nulls, Three-Valued Logic, and Ambiguity in SQL: Critiquing Date's Critique ).

Ambos são referenciados e discutidos detalhadamente em um thread SO relacionado, Opções para eliminar colunas NULLable de um modelo de banco de dados .

Um novo pensamento, uma grande influência na sua escolha de NULL/ NOT NULLé se você estiver usando um framework. Eu uso muito o symfony e o uso NULLde campos de permissão simplifica parte do código e da verificação de dados ao manipular os dados.

Se você não estiver usando uma estrutura ou se estiver usando instruções e processamento sql simples, eu escolheria qualquer opção que você achasse mais simples de acompanhar. Eu geralmente prefiro NULL para que INSERTas instruções não sejam tediosas ao esquecer de definir os campos vazios como NULL.

Tendo que trabalhar com Oracle ( o que não permite diferenciar ) cheguei à seguinte conclusão:

• De um ponto de vista lógico, não importa. Eu realmente não consigo pensar em nenhum exemplo convincente em que a diferenciação entre NULL e string de comprimento zero adiciona qualquer valor no DBMS.

• Do que segue: Você tem uma NULLcoluna capaz que não permite zero-len ''ou uma NOT NULLcoluna que permite zero-len. (Ambos não são possíveis no Oracle, como '' === NULLlá.)

• Pela minha experiência, ''faz muito mais sentido ao processar os dados, pois normalmente você gostaria de processar a ausência de uma string como a string vazia: Concatenação, Comparação, etc.

Para voltar à minha experiência Oracle: Digamos que você queira gerar uma consulta para uma solicitação de pesquisa. Se você (em não Oracle) usa '', pode apenas gerar WHERE columnX = <searchvalue>e funcionará para pesquisas de igualdade. Se usar NULLtem que fazer WHERE columnX=<searchvalue> or (columnX is NULL and searchvalue is NULL).

A segunda lógica, mais complicada, é de fato o que você tem que fazer no Oracle, como NULL e ''é a mesma coisa lá.

Eles também são diferentes do ponto de vista do design:

por exemplo

CREATE TABLE t (
    id INTEGER  NOT NULL,
    name CHARACTER(40),
    CONSTRAINT t_PK PRIMARY KEY (id)
);

CREATE UNIQUE INDEX t_AK1 ON t (name);

Parece:

 \d t
          Table "public.t"
 Column |     Type      | Modifiers
--------+---------------+-----------
 id     | integer       | not null
 name   | character(40) |
Indexes:
    "t_pk" PRIMARY KEY, btree (id)
    "t_ak1" UNIQUE, btree (name)

Vamos inserir alguns dados:

op=# insert into t(id, name ) values ( 1, 'Hello');
INSERT 0 1

op=# insert into t( id, name) values ( 2, '');
INSERT 0 1

op=# insert into t( id, name) values ( 3, '');

ERROR:  duplicate key value violates unique constraint "t_ak1"

Agora vamos tentar com null:

op=# insert into t( id, name) values (4, null );

INSERT 0 1

op=# insert into t( id, name) values (5, null);

INSERT 0 1

Isso é permitido.

Soooooo: nulls não são strings triviais nem o contrário.

Felicidades

Se falamos de teoria, então as regras de Codd dizem que o RDBMS deve tratar NULLos valores de uma maneira especial.

Como exatamente isso é usado depende dos arquitetos de banco de dados, dependendo do domínio real - tarefa - projeto - aplicativo - área.

Depende dos significados. Veja este exemplo: sua coluna armazena o que uma pessoa disse em 12 de agosto de 2020 entre 8h e 9h UTC. As chances são de que

1. uma pessoa disse algo (string não vazia)
2. uma pessoa não disse nada (string vazia)
3. você não sabe o que uma pessoa disse (valor nulo)

Você pode fazer com que seus dados signifiquem o que for mais conveniente para você explorando (ou não) o que é oferecido a você