mysql - txt - load data infile

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

Aquí hay un par de enlaces del 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

Lo leí una vez, que un valor NULL es de 2 bits, mientras que una cadena vacía es solo de 1 bit. El 99% de las veces esto no hará ninguna diferencia, pero en una tabla muy grande cuando no importa si es NULL o '''' , entonces sería mejor usar '''' si esto es cierto.

Cadena nula o vacía: ¿es una mejor que la otra para no representar datos en una columna de 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?

Considera 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 mientras 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.

La mayoría de las veces nulo es mejor. Es probable que haya algunas situaciones en las que haga poca diferencia, pero son pocas. Solo recuerda cuando consultas ese field = '''' no es lo mismo que el field is null (en MySQL, al menos).

Null es mejor "" en realidad representa datos y no registrará lo mismo en tu código

Nulo. Una cadena vacía no es "sin datos", es información que está vacía.

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

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

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).

Use la herramienta correcta 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.

Cree una tabla separada solo para la columna que admite 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 cadenas vacías.

Ninguno. Representa la ausencia de datos como la ausencia de tuplas en una relación.

Por motivos 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.

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.

Como sugirió James Curran arriba, Oracle eligió esta coyuntura bastante crítica para apartarse del SQL estándar al tratar los NULL y cadenas vacías exactamente de la misma manera. Peor que tratarlos de la misma manera, sin embargo, en realidad puede dañar 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.

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ía de las veces, sin embargo, NULL es un estado adicional innecesario que solo 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 es un no valor 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 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 gran problema 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 hecho 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í!

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 del conductor significa que el solicitante o el procesador del 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 tema de no utilizar NULL como principio, hay casos en los que, de hecho, 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.

Encuentro 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.

id: clave principal
product_id: FOREIGN KEY NOT NULL
ref_id: (NULLABLE)

id y product_id area siempre requerido. ref_id se puede establecer en NULL. Sin embargo, si se utiliza cualquier otro valor, debe cumplir la restricción FOREIGN KEY.