Leí un artículo en BBC. Uno de los ejemplos que dijeron fue que las personas con el apellido 'Null' tienen problemas para ingresar sus detalles en algunos sitios web.
No se da ninguna explicación sobre el error al que se enfrentan.
Pero hasta donde sé, la cadena 'Null' y el valor Null real son completamente diferentes (desde el punto de vista de la base de datos).
¿Por qué esto causaría problemas en una base de datos?
No causa problemas con la base de datos. Causa problemas en aplicaciones escritas por desarrolladores que no entienden las bases de datos. La raíz del problema es que gran parte del software relacionado con la base de datos muestra un registro NULO como la cadena NULL . Cuando una aplicación se basa en el formato de cadena de un registro NULL (es probable que también utilice operaciones de comparación que no distingan mayúsculas y minúsculas), dicha aplicación considerará que cualquier cadena "null" es NULL. En consecuencia, esa aplicación considerará que no existe un nombre nulo.
La solución es declarar las columnas no nulas como NOT NULL en la base de datos y no aplicar operaciones de cadena a los registros de la base de datos. La mayoría de los idiomas tienen excelentes API de base de datos que hacen que las interfaces a nivel de cadena sean innecesarias. Siempre deben ser preferibles, también porque cometen otros errores, como la inyección de SQL, con menos probabilidad.
Para responder a su pregunta específica, hay muchos pasos a lo largo de la cadena de eventos entre un formulario web y la base de datos. Si el apellido Null se interpreta erróneamente como un valor NULL , entonces el sistema puede rechazar un nombre perfectamente válido por no ser válido. Esto puede suceder en la capa de la base de datos como explicado por amon . Por cierto, si este es el problema específico, la base de datos también está probablemente abierta a la inyección de SQL, también conocido como el ataque Bobby Tables . Otro paso en la cadena que podría estar causando problemas es el proceso de serialización .
En general, el artículo trataba de un problema mayor. El mundo es un gran lugar desordenado que no siempre se ajusta a nuestras suposiciones. Esto es especialmente evidente cuando intenta internacionalizar su aplicación. Al final del día, necesitamos asegurarnos de que nuestras aplicaciones manejen y codifiquen nuestros datos correctamente . Depende de la empresa decidir cuántos recursos dedicamos a respaldar casos de borde cada vez más complicados. Aunque estoy totalmente de acuerdo con ser inclusivo, entenderé si la empresa decide que "el artista conocido formalmente como Prince" necesita usar un personaje de Unicode para representar su nombre en nuestra base de datos.
Bueno, antes de ingresar a la base de datos, es un elemento DOM, luego una variable javascript pasada, validada y manipulada, luego un valor JSON, luego una variable en cualquier biblioteca JSON de back-end que esté utilizando, luego una variable transmitido, validado y manipulado en su lenguaje de programación backend, luego un elemento de algún tipo de DAO, y luego parte de una cadena SQL. Luego, para recuperar el valor, lo hace todo a la inversa. Esos son muchos lugares donde los programadores pueden cometer errores, y generalmente muchos de ellos sin el beneficio de la escritura estática.
Lo más probable es que sea un problema de programación. Si observa esta respuesta aquí sobre cómo se pasan los valores NULL, podría provocar fácilmente un comportamiento no deseado si fuera "el Sr. Null".
Puede ver que si se pasa algún elemento de datos como NULL, los datos se interpolarán como una base de datos nula en la base de datos.
"NULL"! = Base de datos nula
Algunos casos de uso y comportamiento relacionado ...
Digamos que el apellido fue marcado en la base de datos como no nulo, ahora, cuando se insertan los datos, se interpretarán como NULL y fallarán en la inserción.
Otro caso es, digamos que el apellido era anulable en la base de datos. El Sr. NULL se inserta y se transforma en DBNull.Value que no es lo mismo que "NULL". Después de la inserción, no podemos encontrar al Sr. Null porque su apellido no es "NULL", pero en realidad es un valor nulo de la base de datos.
Entonces, esos serían 2 casos de problemas. Como señala @Amon, las bases de datos en sí mismas no tienen problemas con los valores nulos, aunque se debe entender cómo se manejan los nulos en cada instancia de RDMS ya que habrá diferencias entre los diferentes proveedores.
Yo atribuiría el problema a la programación descuidada y al diseño deficiente de algunas implementaciones de SQL. "Nulo" el nombre siempre debe presentarse e interpretarse con comillas. nulo, el valor de la base de datos, siempre debe presentarse sin comillas; pero al escribir código ad-hoc, es Es fácil deslizarse en el paradigma de "cualquier cosa hará" y aceptar cosas que se cree que son una cadena en forma no entre comillas.
Esto se complica por el hecho de que otros tipos de datos; números por ejemplo, se puede y se acepta en cualquiera de las dos formas porque la interpretación no es ambigua.
Un problema, fundamentalmente, es que el término "nulo" se aplica a dos conceptos de base de datos diferentes, a veces utilizando el contexto para distinguirlos:
Si bien el contexto a veces puede ser suficiente para distinguir entre esos conceptos, hay momentos en que realmente no lo es. Si uno usa un registro para mantener una consulta de búsqueda, por ejemplo, debería haber una diferencia entre decir "Quiero a alguien con el nombre de [lo que sea], sin apellido", en lugar de "Quiero a alguien cuyo nombre es [ lo que sea] pero cuyo apellido es desconocido ". Muchos motores de base de datos tienen un sesgo hacia un significado u otro, pero no todos son iguales. El código que espera que un motor de base de datos funcione de una manera puede funcionar incorrectamente si se ejecuta en un motor diferente que funciona de manera diferente.
La mayoría de las respuestas existentes se centran en las partes que no son SQL de una aplicación, pero también puede haber un problema en SQL:
Si se le indica que filtre los registros donde el apellido de un usuario no está disponible, alguien que no entienda muy bien SQL puede escribir un filtro WHERE u.lastname != 'NULL' . Debido a la forma en que funciona SQL, esto parecerá comprobar si u.lastname IS NOT NULL : todos los registros NULL se filtran. Todos los registros que no sean NULL permanecen.
Excepto, por supuesto, los registros donde u.lastname == 'NULL' , pero es posible que no haya ningún registro disponible durante la prueba.
Esto se vuelve más probable si el SQL es generado por algún tipo de marco, donde ese marco no expone una forma fácilmente accesible para verificar que no haya NULL -ness con parámetros, y alguien se da cuenta "hey, si yo Pase la cadena NULL , ¡hace exactamente lo que quiero! "