Como um sobrenome Null causa problemas em muitos bancos de dados?

Não causa problemas no banco de dados. Isso causa problemas em aplicativos escritos por desenvolvedores que não entendem bancos de dados. Na raiz do problema, muitos softwares relacionados ao banco de dados exibem um registro NULL como a string NULL . Quando um aplicativo, em seguida, depende do formulário de seqüência de caracteres de um registro NULL (provavelmente também usando operações de comparação sem distinção entre maiúsculas e minúsculas), esse aplicativo considerará qualquer seqüência "null" como NULL. Consequentemente, um nome Nulo seria considerado inexistente por esse aplicativo.

A solução é declarar colunas não nulas como NOT NULL no banco de dados e não aplicar operações de cadeia de caracteres aos registros do banco de dados. A maioria das linguagens possui excelentes APIs de banco de dados que tornam desnecessárias as interfaces em nível de string. Eles devem sempre ser preferidos, também porque eles fazem com que outros erros, como a injeção de SQL, sejam menos prováveis.

Para responder à sua pergunta específica, há várias etapas na cadeia de eventos entre um formulário da Web e o banco de dados. Se o último nome Null for erroneamente interpretado como um valor NULL , o sistema pode rejeitar um nome perfeitamente válido como sendo inválido. Isso pode acontecer na camada de banco de dados como explicado por amon . Aliás, se este é o problema específico, então o banco de dados também é provavelmente aberto para injeção de SQL AKA o ataque Bobby Tables . Outra etapa na cadeia que pode estar causando problemas é o processo de serialização .

No geral, o artigo tratou de um problema maior. O mundo é um lugar grande e confuso que nem sempre está de acordo com nossas suposições. Isso é especialmente evidente quando você tenta internacionalizar seu aplicativo. No final do dia, precisamos garantir que nossos aplicativos gerenciem e codifiquem nossos dados corretamente . Cabe ao negócio decidir quantos recursos dedicamos para apoiar casos de borda cada vez mais complicados. Embora eu suporte totalmente a inclusão, vou entender se a empresa decidir que "o artista formalmente conhecido como Prince" precisa usar um caractere Unicode para representar seu nome em nosso banco de dados.

Bem, antes de entrar no banco de dados, ele é um elemento DOM, uma variável javascript transmitida, validada e manipulada, um valor JSON e uma variável em qualquer biblioteca JSON de backend que estiver usando e, em seguida, uma variável passados, validados e manipulados em sua linguagem de programação de backend, então um elemento de algum tipo de DAO, em seguida, parte de uma string SQL. Então, para recuperar o valor, você faz tudo ao contrário. Isso é um monte de lugares para os programadores cometem erros, e geralmente muito disso sem o benefício da digitação estática.

O mais provável é que seja um problema de programação. Se você olhar para esta resposta aqui sobre como os NULLs estão sendo passados, você poderia facilmente causar algum comportamento indesejado se fosse "Mr. Null".

link

Você pode ver que, se algum elemento de dados fosse transmitido como NULL, os dados seriam interpolados como um banco de dados nulo no banco de dados.

"NULL"! = Null do banco de dados

Alguns casos de uso e comportamento relacionado ...

Digamos que o sobrenome tenha sido marcado no banco de dados como não nulo; agora, quando os dados forem inseridos, eles serão interpretados como NULL e falharão na inserção.

Outro caso é digamos que o sobrenome seja anulável no banco de dados. O Sr. NULL é inserido e é transformado em DBNull.Value, que não é o mesmo que "NULL". Após a inserção, não podemos encontrar o Sr. Nulo, porque o seu sobrenome não é "NULL", mas, na realidade, um valor nulo do banco de dados.

Então, esses seriam dois casos de problemas. Como aponta o @Amon, os próprios bancos de dados não têm problemas com nulos, embora seja necessário entender como os nulos são tratados em cada instância do RDMS, pois haverá diferenças entre os diferentes fornecedores.

Eu atribuo o problema à programação malfeita e ao design pobre de algumas implementações do SQL. "Nulo" o nome deve sempre ser apresentado e interpretado com aspas. null, o valor do banco de dados, deve sempre ser apresentado sem aspas; mas ao escrever código ad-hoc, é É fácil adentrar o paradigma de "qualquer coisa serve" e aceitar as coisas que se acredita serem uma string em forma não citada.

Isso é agravado pelo fato de que outros tipos de dados; números por exemplo, podem e são aceitos em qualquer forma porque a interpretação é inequívoca.

Um problema, fundamentalmente, é que o termo "null" é aplicado a dois conceitos diferentes de banco de dados, algumas vezes usando contexto para distinguir entre eles:

1. Algo não tem um valor conhecido
2. Algo é conhecido por não ter valor

Embora o contexto às vezes possa ser suficiente para distinguir entre esses conceitos, há momentos em que isso não acontece. Se alguém estiver usando um registro para realizar uma consulta de pesquisa, por exemplo, deve haver uma diferença entre dizer "quero alguém pelo nome de [o que quer que], sem sobrenome", versus "Eu quero alguém cujo primeiro nome é [ seja qual for] mas cujo sobrenome é desconhecido. " Muitos mecanismos de banco de dados têm um viés em um sentido ou outro, mas não são todos iguais. O código que espera que um mecanismo de banco de dados funcione de uma maneira pode funcionar incorretamente se for executado em um mecanismo diferente que seja executado de maneira diferente.

A maioria das respostas existentes se concentra nas partes não-SQL de um aplicativo, mas pode haver um problema no SQL também:

Se for instruído a filtrar os registros em que o sobrenome de um usuário não está disponível, alguém que não entende muito bem o SQL pode escrever um filtro WHERE u.lastname != 'NULL' . Devido ao modo como o SQL funciona, isso parecerá verificar se u.lastname IS NOT NULL : all NULL records foi filtrado. Todos os registros que não são NULL permanecem.

Exceto, é claro, para registros em que u.lastname == 'NULL' , mas pode não ter havido nenhum registro disponível durante o teste.

Isso se torna mais provável se o SQL for gerado por algum tipo de framework, onde esse framework não expõe uma maneira facilmente acessível de verificar se há NULL -ness com parâmetros, e alguém percebe "hey, se eu passe na string NULL , faz exatamente o que eu quero! "