Pensei nisso um pouco tentando ser positivo e justificar a necessidade de usar um valor arbitrário em vez de um nulo e parece (pelo menos para mim) não haver uma razão válida para isso, exceto talvez em um conjunto de dados fechado de mineração de dados para melhorar e simplificar o desempenho e as consultas, e somente nos casos em que os números não são valores que podem distorcer os dados. Mesmo isso teria que ser considerado com cuidado. Em todas as situações do mundo real, dar valor a nulo não é uma boa prática. Isso transforma uma definição de coluna NOT NULL do seu amigo para o inimigo, uma vez que realmente não é verdade.
É uma coisa muito diferente dizer que nosso aplicativo não deve aceitar um valor NULL para algumas (ou mesmo todas) colunas. Isso é sensato e é uma boa prática e há benefícios bem documentados em não permitir nulos (chaves e índices e cálculos estatísticos, por exemplo). No entanto, atribuir um valor a "sentar no lugar" de um nulo não é o mesmo. É o caminho certo para você, já que você precisa primeiro selecionar um valor que nunca será usado, filtrar esse valor como seria o nulo e lembre-se de não usá-lo em cálculos e resumos e removê-lo dos feeds de dados externos . Isso é pelo menos tão ruim quanto usar um nulo para representar um valor real, que é o que você diz a si mesmo que está evitando, mas não está.
A maioria dos problemas que os nulos causam, uma vez entendidos, pode ser tratada (melhor normalização, índices baseados em funções ou bitmap ou com um simples WHERE x IS NOT NULL). Você acha que em alguma empresa de telecomunicações de grande porte ou na Amazon na reunião mensal de desempenho, algum DBA está delineando esse grande plano para acelerar um pouco as consultas em seus enormes conjuntos de dados "substituindo null por um valor arbitrário, algo como -5000 ou algo assim - Estou aberto ao valor ... ". Ou você acha que eles gastam seu tempo dividido entre um melhor design de aplicativo para filtrar nulos indesejados e otimizar a consulta com base nos dados reais que recebem ? Tudo bem, talvez uma reunião mensal seja um pouco otimista, mas sempre que isso acontece, posso garantir que "Substituir nulos por -5000 (ou o que for) para uma API melhor" não é um item da agenda.
Para mim, é bom dizer que não aceitarei dados ausentes (você deve ter uma idade, preço ou código de região ou qualquer outra coisa) e, às vezes, é bom dizer que para esta coluna há um valor padrão que será inserido se você não coloca outra coisa. Não é bom reservar um valor para significar nulo. Pense nos campos de nome do meio como um exemplo. Às vezes, elas não existem, pois os pais têm preguiça de preencher todas as caixas. Adicionamos "nenhum" ou "ausente" ou "desconhecido" aos nossos dados para melhorar nossas pesquisas? Não, porque pode haver pessoas estranhas que mudam seus nomes para esses valores e, portanto, quando imprimimos os dados, não sabemos se devemos incluí-los ou não. É um exemplo simples, mas abrangente. Conhecemos o NULL e temos funções integradas previsíveis para lidar com isso. Você não pode codificar isso melhor.
Se nenhuma resposta (ou NULL) não for uma resposta válida para sua solicitação de entrada, não permita isso no aplicativo ou no banco de dados; se for uma boa resposta, você deverá permitir tanto no aplicativo quanto no banco de dados e lidar com como uma resposta válida. Se fizer parte de um conjunto de respostas válidas, seu banco de dados deverá ser projetado para armazená-lo. Afinal, você não diz ei, os campos numéricos são tão chatos que permitem armazenar números em blobs e usar imagens de animais selvagens para representar cada número, porque isso é loucura (legal, mas louca). Também não decidimos que não gostamos da letra B e, como um pesadelo cruel da Vila Sésamo, a substituímos por um # em nossos dados. Se B não for uma resposta, queremos que digamos ao usuário "Ei, você não pode colocar um B aqui". Então, por que tratar nulo de maneira diferente?
Portanto, evite os nulos que você não deseja no nível do aplicativo e lide com eles no banco de dados, onde você os aceita de outra forma tão certo quanto girafa + girafa = hipopótamo, sua inútil discussão de dados causará problemas.