Cadena nula o vacía: ¿es una mejor que la otra para no representar datos en una columna de la tabla? (Específicamente utilizo MySQL, pero estoy pensando que esto es independiente del sistema). ¿Hay ventajas/desventajas importantes al usar una sobre la otra, o es simplemente una preferencia de programador?¿Debo usar NULL o una cadena vacía para no representar datos en la columna de la tabla?
Estoy totalmente en desacuerdo con todos los que dicen que usan incondicionalmente NULL. Permitir que una columna sea NULL introduce un estado adicional que no tendrías si configuraras la columna como NOT NULL. No haga esto si no necesita el estado adicional. Es decir, si no puede encontrar una diferencia entre el significado de cadena vacía y el significado de nulo, configure la columna como NOT NULL y use una cadena vacía para representar empty. Representar lo mismo de dos maneras diferentes es una mala idea.
La mayoría de las personas que le dijeron que use NULL también dieron un ejemplo en el que NULL significaría algo diferente a la cadena vacía. Y en esos ejemplos, tienen razón.
La mayor parte del tiempo, sin embargo, NULL es un estado extra innecesario que simplemente obliga a los programadores a manejar más casos. Como han mencionado otros, Oracle no permite que exista este estado adicional porque trata a NULL y cadena vacía como la misma cosa (es imposible almacenar una cadena vacía en una columna que no permite el nulo en Oracle).
Null. Una cadena vacía no es "sin datos", es información que está vacía.
nulo es mejor "" en realidad representa los datos y no lo puedo registrar el mismo en su código
Por lo que yo puedo decir, Oracle no distingue la diferencia.
select 1 from (select '' as col from dual) where col is null;
NULLs no se almacenan en los índices. Existe la posibilidad de diferencias en el rendimiento, dependiendo de la consulta. – EvilTeach
Correcto, Oracle no cumple con el estándar SQL en este caso. El OP preguntaba por MySQL, sin embargo, que distingue correctamente entre NULL y ''. –
Estaba abordando el comentario de james curran – EvilTeach
La mayor parte del tiempo null es mejor. Es probable que haya algunas situaciones en las que haga poca diferencia, pero son pocas. Solo recuerda cuando consultas que field = '' no es lo mismo que field is null (en MySQL, al menos).
Considere por qué no hay datos en la columna. ¿Significa que el diseño de la mesa es descuidado? A pesar de que no le agraden los nulos, hay ocasiones en que son apropiados (o lo suficientemente adecuados) y el sistema generalmente no morirá. Simplemente nunca permita nulos en nada que sea una clave candidata (clave primaria o alternativa).
En el contexto del modelo de base de datos relacional, null indica "sin valor" o "valor desconocido". Existe exactamente para el propósito que describes.
ACTUALIZACIÓN: Perdón, olvidé agregar que aunque la mayoría (¿todos?) RDMBS usan esta misma definición para null, existen diferencias matizadas en cómo se maneja null. Por ejemplo, MySQL y Oracle permiten nulos múltiples en una columna ÚNICA (o conjunto de columnas), porque null no es un valor, y no puede considerarse único (null! = Null). Pero la última vez que utilicé MS SQL Server, solo permitía un único nulo. Por lo tanto, es posible que deba considerar el comportamiento RDBMS y si la columna en cuestión estará restringida o indexada.
Aquí hay un par de enlaces desde el sitio de MySQL:
http://dev.mysql.com/doc/refman/5.0/en/problems-with-null.html
http://dev.mysql.com/doc/refman/5.0/en/working-with-null.html
leí una vez, que un valor NULL es de 2 bits, donde como una cadena vacía es solamente 1 bit . El 99% de las veces esto no hará ninguna diferencia, pero en una tabla muy grande cuando no importa si NULL o '', entonces podría ser mejor usar '' si esto es cierto.
Siempre use NULL. Considere la diferencia entre "No sé cuál es el número de teléfono de esta persona" (NULO) y "esta persona lo dejó en blanco" (en blanco).
Utilice la herramienta adecuada para el trabajo. NULL puede significar que no se proporcionó ningún valor (aún) o puede significar que no se aplica ningún valor.
Pero una cadena vacía es información también. Puede significar que un valor es aplicable, y se dio, pero resulta ser una cadena vacía.
Permitir que una columna contenga tanto NULL como '' le da la oportunidad de distinguir entre estos casos. En cualquier caso, no es bueno usar uno para significar el otro.
Tenga en cuenta que en la concatenación de cadenas, cualquier cosa combinada con NULL produce NULL.Por ejemplo: CONCAT (NULL, 'foo') produce NULL. Aprenda a utilizar la función COALESCE() si desea convertir NULL a algún valor predeterminado en una expresión SQL.
Ninguno. Representa la ausencia de datos como la ausencia de tuplas en una relación.
Por razones de rendimiento, es posible que desee evitar uniones en algunos RDBMS, pero intente diseñar el modelo de modo que la información que puede faltar esté en una relación separada.
Crea una tabla separada para solo la columna que admite nulos y una clave foránea para la tabla principal. Si un registro no tiene datos para esa columna, entonces no tendrá un registro en la segunda tabla. Esta es la solución más limpia y no tiene que preocuparse por manejar nulos o dar un significado especial a cadenas vacías.
Hay una excepción importante. Bill Karwin declaró "CONCAT (NULL, 'foo') produce NULL", lo cual es cierto para la mayoría de los RDBMS pero NO para Oracle.
Según lo sugerido por James Curran anteriormente, Oracle eligió esta coyuntura bastante crítica para apartarse del SQL estándar al tratar los NULL y las cadenas vacías exactamente igual. Peor que simplemente tratarlos de la misma manera, sin embargo, puede corromper el significado de un valor NULL al devolver algo que no sea NULL al concatenar.
Específicamente, en el oráculo CONCAT (NULL, 'foo') produce 'foo'. Gracias a Oracle, ahora perdí mis valores nulos que pueden no importarle, pero seguro que hace una diferencia cuando los datos se pasan a otros RDBMS para su posterior procesamiento.
NULL es un valor nulo que debe ser relegado a las edades oscuras desde donde brotó. Descubrí que se requiere una cantidad no trivial de programación para manejar casos NULL especiales que podrían manejarse fácilmente con un valor predeterminado.
Establezca el valor predeterminado para su columna como una cadena vacía. Fuerce a la columna para que no permita el nulo, lo que probablemente nunca ocurra una vez que asigne un valor predeterminado. Escriba su código felizmente ignorando el caso donde el valor de la columna es nulo.
Un problema enorme que siempre he tenido con NULL es que "SELECT * from tbl WHERE column = NULL" siempre devolverá un conjunto de resultados vacío. NULL nunca puede ser igual a nada, incluido NULL. La palabra clave speical "column is null" es la única forma de verificar que algo sea nulo. Si retrocede desde el valor nulo, la comparación tendrá éxito: "columna = ''" 7 filas devueltas.
He realizado dos implementaciones principales de DB desde cero, donde al final me he arrepentido de haber usado NULL. La próxima vez, no hay NULL para mí!
Si conoce la sintaxis adecuada para verificar si un valor es nulo, ¿por qué es un problema? –
Generación dinámica de consultas. Todo esto es un punto discutible, desde entonces he ido a una biblioteca de persistencia y no he mirado hacia atrás =) – Kieveli
Un valor "sin datos" en una columna debe representarse por un valor predeterminado. Recuerde que NULL significa un valor desconocido, es decir, la columna puede tener un valor o no, pero usted no lo sabe a partir de este momento.
En un sistema de solicitud de préstamo, por ejemplo, un valor NULO en el campo Número de licencia de conducir significa que el solicitante o el procesador de préstamo no ingresaron el número de licencia de conducir. El valor NULL no significa automáticamente que el solicitante no tenga una licencia. Él puede o no tener una licencia, simplemente no lo sabe, es por eso que es NULO.
La ambigüedad radica en las columnas de cadenas. Una columna numérica obviamente contiene un cero si no hay ningún valor. ¿Cómo se puede representar una cadena sin valor? En el ejemplo anterior, para los solicitantes sin licencia de conducir, puede asignar un valor predeterminado arbitrario como "ninguno" o mejor aún una cadena vacía. Solo asegúrate de utilizar el valor vacío predeterminado en tus otras tablas para mayor coherencia.
En el problema de no utilizar NULL como principio, hay casos en los que son esenciales. Como alguien que trabaja extensamente con estadísticas, es común que los proveedores de datos le proporcionen conjuntos de datos con datos incompletos. Por ejemplo, en un conjunto de datos de PIB por país, puede encontrar cifras del PIB faltantes en los años anteriores y posteriores. Una razón es que no hay datos oficiales de esos años del gobierno del país. Será incorrecto concluir que su PBI es cero (¡DUH!) Y mostrar un valor cero en los datos extraídos o en un gráfico. El valor correcto es NULL, lo que significa que todavía no tienes los datos. El usuario final interpreta correctamente los puntos de datos faltantes en los datos y gráficos extraídos como NOT zero. Además, no causará errores en tus cálculos, especialmente cuando haces promedios.
Algunas "reglas" que tienen sentido teóricamente serían de hecho una solución pobre o incorrecta en su caso.
Creo que los valores NULL son útiles para la integridad referencial. En el caso de MySQL, si un campo está configurado como NOT NULL, una inserción requiere que se establezcan los datos; de lo contrario, NULL es un valor posible y la restricción de clave externa no se aplica.
Identificación y el área product_id siempre se requiere. ref_id se puede establecer en NULL. Sin embargo, si se utiliza cualquier otro valor, debe cumplir la restricción FOREIGN KEY.
Otro puntero a favor de esta vista: una vez que ha ido más allá de la base de datos a la aplicación que lo usa, puede encontrar (como lo hago) que su lógica es solo de dos estados. En otras palabras, tienes datos o no. Si su lógica de alto nivel funciona de la siguiente manera, no tiene sentido convertir un tercer estado en la base de datos, y luego darse cuenta de que no sabe lo que significa, en todo caso. – EML