50 Shades of NULL – Os diferentes significados de NULL em SQL

Os diferentes significados de NULL

• O valor "indefinido" , ou seja, o valor que ainda não está definido (provavelmente por razões técnicas), mas pode ser definido posteriormente. Pense em uma pessoa que queremos adicionar ao banco de dados para usá-lo em outras tabelas. Em algum estágio posterior, adicionaremos o trabalho dessa pessoa.
• O valor "desconhecido" , ou seja, o valor que não sabemos (e talvez nunca saibamos). Talvez não possamos mais perguntar a essa pessoa ou a seus parentes sobre sua data de nascimento – a informação será perdida para sempre. Mas ainda queremos modelar a pessoa, então usamos NULL no sentido de UNKNOWN (que é seu verdadeiro significado em SQL, como veremos mais adiante).
• O valor "opcional" , ou seja, o valor que não precisa ser definido. Observe que o valor “opcional” também aparece no caso de um OUTER JOIN, quando a junção externa não produz nenhum valor em um lado do relacionamento. Ou também ao usar GROUPING SETS, onde diferentes combinações de colunas GROUP BY são combinadas (ou deixadas em branco).
• O valor "excluído" ou "evitado" , ou seja, o valor que não queremos especificar. Talvez costumamos registrar o estado civil de uma pessoa como é feito em algumas jurisdições, mas não em outras, onde não é legal registrar nenhum dado pessoal desse tipo. Portanto, não queremos saber esse valor em alguns casos.
• O valor "especial" em um determinado contexto , ou seja, o valor que não podemos modelar de outra forma na faixa de valores possíveis. Isso geralmente é feito ao trabalhar com intervalos de datas. Vamos supor que o trabalho de uma pessoa seja limitado por duas datas e, se a pessoa estiver trabalhando nesse cargo, usaremos NULL para dizer que o período é ilimitado no final do período.
• O NULO "acidental" , ou seja, o valor NULL que é apenas NULL porque os desenvolvedores não prestaram atenção. Na ausência de uma restrição NOT NULL explícita, a maioria dos bancos de dados assume que as colunas são anuláveis. E uma vez que as colunas são anuláveis, os desenvolvedores podem simplesmente "acidentalmente" colocar valores NULL em suas linhas, onde eles nem pretendiam.

CREATE TABLE company (
    id int NOT NULL,
    name text NOT NULL,
    CONSTRAINT company_pk PRIMARY KEY (id)
);
CREATE TABLE job (
    person_id int NOT NULL,
    start_date date NOT NULL,

    -- If end_date IS NULL, the “special value” of an unbounded
    -- interval is encoded
    end_date date NULL,
    description text NOT NULL,

    -- A job doesn’t have to be done at a company. It is “optional”.
    company_id int NULL,
    CONSTRAINT job_pk PRIMARY KEY (person_id,start_date),
    CONSTRAINT job_company FOREIGN KEY (company_id) 
        REFERENCES company (id) 
);
CREATE TABLE person (
    id int  NOT NULL,
    first_name text NOT NULL,

    -- Some people need to be created in the database before we
    -- know their last_names. It is “undefined”
    last_name text NULL,

    -- We may not know the date_of_birth. It is “unknown”
    date_of_birth date NULL,

    -- In some situations, we must not define any marital_status.
    -- It is “deleted”
    marital_status int NULL,
    CONSTRAINT person_pk PRIMARY KEY (id),
    CONSTRAINT job_person FOREIGN KEY (person_id)
        REFERENCES person (id)
); 

As pessoas sempre discutiram sobre a ausência de um valor

De volta à realidade:NULL em SQL

SELECT * FROM person WHERE marital_status != 'married'

Infelizmente, devido à lógica de três valores e NULL do SQL, a consulta acima não retornará os valores que não possuem nenhum marital_status explícito. Portanto, precisaremos escrever um predicado explícito adicional:

SELECT * FROM person 
WHERE marital_status != 'married'
OR marital_status IS NULL

Ou, forçamos o valor para algum valor NOT NULL antes de compará-lo

SELECT * FROM person
WHERE COALESCE(marital_status, 'null') != 'married'

A lógica de três valores é difícil. E não é o único problema com NULL no SQL. Aqui estão mais desvantagens de usar NULL:

• Existe apenas um NULL, quando realmente queríamos codificar vários valores “ausentes” ou “especiais” diferentes. O intervalo de valores especiais úteis depende muito do domínio e dos tipos de dados usados. No entanto, o conhecimento do domínio é sempre necessário para interpretar corretamente o significado de uma coluna anulável, e as consultas devem ser projetadas com cuidado para evitar que os resultados errados sejam retornados, como vimos acima.
• Novamente, a lógica de três valores é muito difícil de acertar. Embora o exemplo acima ainda seja bastante simples, o que você acha que a consulta a seguir produzirá?

  SELECT * FROM person 
  WHERE marital_status NOT IN ('married', NULL)
  

  Exatamente. Não vai render nada, como explicado neste artigo aqui. Em suma, a consulta acima é a mesma que a abaixo:
  

  SELECT * FROM person 
  WHERE marital_status != 'married'
  AND marital_status != NULL -- This is always NULL / UNKNOWN
  

• 
  O banco de dados Oracle trata NULL e a string vazia '' como a mesma coisa. Isso é muito complicado, pois você não notará imediatamente por que a consulta a seguir sempre retorna um resultado vazio:
  
  

  SELECT * FROM person 
  WHERE marital_status NOT IN ('married', '')
  

  
  
• 
  Oracle (novamente) não coloca valores NULL em índices. Esta é a fonte de muitos problemas de desempenho desagradáveis, por exemplo, quando você está usando uma coluna anulável em um predicado NOT IN como tal:
  
  

  SELECT * FROM person 
  WHERE marital_status NOT IN (
    SELECT some_nullable_column
    FROM some_table
  )
  

  
  

  Com o Oracle, o anti-join acima resultará em uma verificação completa da tabela, independentemente de você ter um índice em some_nullable_column. Por causa da lógica de três valores e porque o Oracle não coloca NULLs em índices, o mecanismo precisará acessar a tabela e verificar todos os valores apenas para ter certeza de que não há pelo menos um valor NULL no conjunto, o que tornaria o predicado inteiro DESCONHECIDO.
  

Conclusão

Lukas Eder é fundador e CEO da Data Geekery GmbH, localizada em Zurique, Suíça. A Data Geekery vende produtos e serviços de banco de dados em Java e SQL desde 2013.

Desde seus estudos de mestrado na EPFL em 2006, ele é fascinado pela interação de Java e SQL. A maior parte dessa experiência ele obteve na área de E-Banking suíço através de várias variantes (JDBC, Hibernate, principalmente com Oracle). Ele tem o prazer de compartilhar esse conhecimento em várias conferências, JUGs, apresentações internas e no blog da empresa.