¿Debo usar NULL o una cadena vacía para representar que no hay datos en la columna de la tabla?

StackOverflow https://stackoverflow.com/questions/167952

  •  03-07-2019
  •  | 
  •  

Pregunta

Cadena nula o vacía: ¿es una mejor que la otra para no representar datos en una columna de la tabla? (Utilizo MySQL específicamente, pero creo que esto es independiente del sistema). ¿Existen ventajas / desventajas importantes al usar una sobre la otra, o es simplemente la preferencia del programador?

¿Fue útil?

Solución

Estoy totalmente en desacuerdo con todos los que dicen usar NULL incondicionalmente. Permitir que una columna sea NULA introduce un estado adicional que no tendría si configurara la columna como NO NULA. No hagas esto si no necesitas 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 NO NULA y use la cadena vacía para que represente el vacío. Representar lo mismo de dos maneras diferentes es una mala idea.

La mayoría de las personas que le dijeron que usara NULL también dieron un ejemplo donde NULL significaría algo diferente a una cadena vacía. Y en esos ejemplos, tienen razón.

Sin embargo, la mayoría de las veces, NULL es un estado adicional innecesario que solo obliga a los programadores a tener que manejar más casos. Como han mencionado otros, Oracle no permite que exista este estado adicional porque trata NULL y una cadena vacía como lo mismo (es imposible almacenar una cadena vacía en una columna que no permita nulos en Oracle).

Otros consejos

Nulo. Una cadena vacía no es " no hay datos " ;, son datos que están vacíos.

Nulo es mejor " " en realidad representa datos y no se registrará lo mismo en su código

En el contexto del modelo de base de datos relacional, nulo indica que "no hay valor" o " valor desconocido " ;. Existe exactamente para el propósito que usted describe.

ACTUALIZACIÓN: Perdón, olvidé agregar que aunque la mayoría de las RDMBS (todas?) usan esta misma definición para null, existen diferencias detalladas en la forma en que se maneja el nulo. Por ejemplo, MySQL y Oracle permiten varios valores nulos en una columna ÚNICA (o conjunto de columnas), porque el valor nulo no es un valor y no se puede considerar único (nulo! = Nulo). Pero la última vez que utilicé MS SQL Server, solo permitía un solo nulo. Por lo tanto, es posible que deba considerar el comportamiento de RDBMS y si la columna en cuestión será restringida o indexada.

Ninguno. Representa la ausencia de datos como 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 para que la información que pueda faltar esté en una relación separada.

Aquí hay un par de enlaces desde el sitio 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 de NULL es de 2 bits, mientras que una cadena vacía es de solo 1 bit. 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 para 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 " (NULL) 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 (todavía) o puede significar que no se aplica ningún valor.

Pero una cadena vacía también es información. Puede significar que un valor es aplicable y se dio, pero resulta que es una cadena vacía.

Permitir que una columna contenga NULL y '' 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 usar la función COALESCE () si desea convertir NULL a algún valor predeterminado en una expresión SQL.

La mayoría de las veces null es mejor. Probablemente hay algunas situaciones donde hay poca diferencia, pero son pocas. Solo recuerde que cuando consulta el campo = '' no es lo mismo que el campo es nulo (en MySQL, al menos).

Por lo que puedo decir, Oracle no distingue una diferencia.

select 1 from (select '' as col  from dual) where col is null;

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 gusten los valores nulos, hay ocasiones en que son apropiadas (o, lo suficientemente apropiadas) y el sistema generalmente no muere. Simplemente nunca permita valores nulos en nada que sea una clave candidata (clave principal o alternativa).

Cree una tabla separada solo para la columna que admite valores nulos y una clave externa 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 las cadenas vacías.

NULL es un valor sin valor que debe ser relegado a las edades oscuras de donde surgió. Descubrí que hay una cantidad no trivial de programación requerida para manejar casos NULL especiales que podrían manejarse fácilmente con un valor predeterminado.

Establezca el valor predeterminado para que su columna sea una cadena vacía. Haga que la columna no permita el valor nulo, lo que probablemente nunca sucederá una vez que asigne un valor predeterminado. Escriba su código felizmente ignorando el caso donde el valor de la columna es nulo.

Un gran problema que siempre tuve 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 columna de palabras clave específicas es nula " Es la única forma de comprobar si algo es nulo. Si se aleja de null, la comparación será satisfactoria: " column = '' " 7 filas devueltas.

He hecho dos implementaciones de DB principales desde cero, donde al final me he arrepentido de usar NULL. La próxima vez, no hay NULL para mí!

Hay una excepción importante. Bill Karwin declaró que "CONCAT (NULL, 'foo') produce NULL " lo cual es cierto para la mayoría de los RDBMS, pero NO para Oracle.

Como lo sugirió James Curran anteriormente, Oracle eligió esta coyuntura bastante crítica para apartarse del SQL estándar tratando los NULL y las cadenas vacías exactamente igual. Sin embargo, lo que es peor que tratarlos de la misma manera, puede corromper el significado de un valor NULL devolviendo algo distinto de NULL al concatenar.

Específicamente, en oracle CONCAT (NULL, 'foo') produce 'foo'. Gracias Oracle, ahora he perdido mis valores nulos, lo que puede que no te importe, pero seguro que marca la diferencia cuando los datos se pasan a otros RDBMS para su posterior procesamiento.

A " sin datos " El valor en una columna debe estar representado por un valor predeterminado. Recuerde que NULL significa un valor desconocido, es decir, la columna puede tener un valor o no, pero 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éstamos 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, por eso es NULL.

La ambigüedad reside en las columnas de cadena. Una columna numérica obviamente contiene un cero si no hay ningún valor. ¿Cómo puedes representar una cadena sin valor? En el ejemplo anterior, para solicitantes sin licencia de conducir, puede asignar un valor predeterminado arbitrario como " ninguno " o mejor aún una cadena vacía. Solo asegúrese de usar el valor vacío predeterminado en sus otras tablas para mantener la coherencia.

Sobre el tema de no usar NULL como principio, hay casos en los que, de hecho, son esenciales. Como alguien que trabaja con estadísticas extensivamente, es común que los proveedores de datos le proporcionen conjuntos de datos con datos incompletos. Por ejemplo, en un conjunto de datos del PIB por país, puede encontrar cifras faltantes del PIB en los años anteriores y posteriores. Una razón es que no hay datos oficiales para esos años del gobierno del país. Será incorrecto concluir que su PIB es cero (¡DUH!) Y mostrar un valor cero en los datos extraídos o en una gráfica. El valor correcto es NULL, lo que significa que aún no tiene los datos. El usuario final interpreta correctamente los puntos de datos faltantes en los datos extraídos y los gráficos NO como cero. Además, no causará errores en tus cálculos, especialmente cuando haces promedios.

Algunas " reglas " Eso tiene sentido en teoría, de hecho, sería una solución pobre o incorrecta en su caso.

Encuentro que los valores NULL son útiles para la integridad referencial. En el caso de MySQL si un campo se establece en NO NULO, entonces una inserción requiere que los datos se establezcan; de lo contrario, NULL es un valor posible y la restricción de clave externa no se aplica.

  1. id: clave principal
  2. product_id: FOREIGN KEY NOT NULL
  3. ref_id: (NULLABLE)

El área de identificación y product_id siempre es necesaria. ref_id se puede establecer en NULL. Sin embargo, si se usa cualquier otro valor, debe cumplir con la restricción FOREIGN KEY.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top