Pensé en esto por un momento tratando de ser positivo y justificar la necesidad de usar un valor arbitrario en lugar de un valor nulo y parece que (al menos para mí) no hay una razón válida para esto, excepto quizás en un conjunto de datos de minería de datos cerrado para mejorar y simplificar el rendimiento y las consultas, y solo en los casos en que los números no sean valores que puedan sesgar los datos. Incluso esto debería ser considerado cuidadosamente. En todas las situaciones del mundo real, dar un valor a nulo no es una buena práctica. Esto convierte una definición de columna NOT NULL de tu amigo a tu enemigo, ya que realmente no es cierto.
Es una cosa muy diferente decir que nuestra aplicación no debería aceptar un valor NULO para algunas (o incluso todas) columnas. Esta es una práctica sensata y buena, y existen beneficios bien documentados al no permitir nulos (claves e índices y cálculos estadísticos, por ejemplo). Sin embargo, asignar un valor para "sentarse en el lugar" de un valor nulo no es lo mismo. Es la barra para su propia espalda, ya que primero debe seleccionar un valor que nunca se usará, filtre este valor como lo haría con el valor nulo y recuerde no usarlo en cálculos y resúmenes y eliminarlo de los datos externos. . Esto es al menos tan malo como usar un valor nulo para representar un valor real, que es lo que te dices a ti mismo que estás evitando, pero no lo eres.
La mayoría de los problemas que causan los nulos, una vez entendidos, pueden tratarse (mejor normalización, índices basados en funciones o mapas de bits o con un simple DONDE x NO ES NULO). ¿Crees que en alguna Telco grande o en Amazon en la reunión de rendimiento mensual algún DBA está delineando este gran plan para acelerar un poco las consultas en sus enormes conjuntos de datos "al reemplazar nulo con un valor arbitrario, algo como -5000, o lo que sea? Estoy abierto al valor ... ". ¿O cree que pasan su tiempo dividido entre un mejor diseño de la aplicación para filtrar los nulos no deseados y la optimización de consultas en función de los datos reales que reciben ? De acuerdo, bien, tal vez una reunión mensual sea un poco optimista, pero cada vez que suceden, puedo asegurarle que "Reemplazar nulos con -5000 (o lo que sea) para una mejor API" no es un tema de la agenda.
Para mí está bien decir que no aceptaré datos faltantes (debe tener una edad o un precio o un código de región o lo que sea) y, a veces, incluso está bien decir que para esta columna hay un valor predeterminado que se ingresará si No pones otra cosa. No está bien dejar de lado un valor que significa nulo. Piense en los campos de segundo nombre como ejemplo. A veces, esto no existirá ya que los padres son demasiado vagos para completar todos los cuadros. ¿Agregamos "ninguno" o "falta" o "desconocido" a nuestros datos para mejorar nuestras búsquedas? No, porque puede haber personas extrañas que cambien sus nombres a estos valores, por lo que cuando imprimimos los datos no sabemos si debemos incluirlos o no. Es un ejemplo simple, pero de largo alcance. Sabemos acerca de NULL y tenemos funciones predecibles incorporadas para manejarlo. No puedes codificar esto mejor.
Si ninguna respuesta (o NULL) no es una respuesta válida a su solicitud de entrada, entonces no la permita en la aplicación o en la base de datos, si es una buena respuesta, debe permitirla tanto en su aplicación como en su base de datos y tratar con Es una respuesta válida. Si es parte de un conjunto de respuestas válidas, su base de datos debe estar diseñada para almacenarla. Después de todo lo que no dices, los campos numéricos son tan aburridos que permite almacenar números en blobs y usar imágenes de animales salvajes para representar cada número, porque eso es loco (genial pero loco). Tampoco decidimos que no nos gusta la letra B, y al igual que una cruel pesadilla de Sesame Street, reemplácela con un # en nuestros datos. Si B no es una respuesta, queremos decirle al usuario "Oye, no puedes poner una B aquí". Entonces, ¿por qué tratar nulo de manera diferente?
Por lo tanto, evite los valores nulos que no desea a nivel de aplicación y trátelos en su base de datos donde los acepte, de lo contrario, tan seguro como giraffe + giraffe = hipopótamo, su disputa de datos sin sentido lo meterá en problemas.