¿Cuáles son los pros y contras de la utilización devalores nulos en SQL en lugar de valores por defecto?SQL: Usando los valores NULL frente a los valores por defecto
PS. Se han hecho muchas preguntas similares aquí pero ninguna responde mi pregunta.
Un valor NULL en bases de datos es un sistema valor que ocupa un byte de almacenamiento e indica que un valor es no está presente en lugar de un espacio o cero o cualquier otro valor predeterminado. El campo en una base de datos que contiene el valor NULL significa que el contenido de esta celda se desconoce en el momento de al mirarlo. Una columna que permite valores NULOS también permite que las filas sean insertadas sin ningún valor en esa columna . Hay varias ventajas y contras del uso de valores NULL en lugar a valores por defecto:
Pros
valor NULL no tiene los datos tipo, por lo tanto, se pueden insertar a cualquier estructura de datos y cualquier base de datos columna. Los valores predeterminados, en la otra mano , deben tener su tipo de datos especificado y un valor predeterminado en una columna puede tener el mismo aspecto en otra columna , pero podría ser de otro tipo .
NULL se utiliza a menudo en esquemas donde un valor es opcional. Es un método conveniente para omitir la entrada de datos para campos desconocidos sin tener que implementar reglas adicionales, como almacenar valores negativos en un número entero campo para representar los datos omitidos.
Dado que el valor NULL solo ocupa 1 bit de espacio de memoria, pueden ser útiles al optimizar la base de datos. El uso de esos valores es mucho más eficiente que los valores predeterminados, p. 8 bits de caracteres y número entero 16bits.
Mientras que los requisitos del sistema pueden cambian con el tiempo y el valor predeterminado tipos con ellos, el valor NULL es siempre NULL lo que no hay necesidad de actualizar el tipo de datos .
Asignación No es nulo a esquemas de tablas también puede ayudar con la validación de mesa, en un sentido que la columna con Not criterios nulos requerirá un valor de pueden insertar imágenes. Los valores predeterminados no tienen estas capacidades.
Contras
valores NULL se confunden fácilmente con cadenas de caracteres vacíos, que devuelven un valor en blanco para el usuario cuando seleccionado. En este sentido, los valores predeterminados de son menos confusos y son la opción más segura de , a menos que el valor predeterminado esté configurado en la cadena vacía.
Si los valores NULL son permitidos en la base de datos , que pueden hacer que el diseñador algo más de tiempo y el trabajo, ya que pueden hacen que la lógica de la base de datos más complicado, especialmente cuando hay un montón de comparaciones con valores nulos en lugar.
Fuente: Pro and cons
Además, el uso de NULLS da lugar a tres lógica valorada. Un booleano, como X = 3, tiene un valor de verdadero si X es 3. Tiene un valor de falso si X tiene un valor distinto de 3, pero no es NULO. Y si X es NULL, el booleano tiene un valor de "Desconocido". Desconocido es un tercer valor lógico. Esto puede ser desconcertante para las personas que están acostumbradas a la lógica de dos valores. –
El [enlace] (http://www.arthurjach.co.uk/blog/2009/03/25/pros-and-cons-of-using-null-values-in-databases-and-sql/) es putrefacción –
Para mí, son algo ortogonales.
Los valores predeterminados le permiten modificar gráficamente su esquema de base de datos (piense en agregar columnas) sin tener que modificar el código del cliente. Además, ahorran algo de tipeo, pero confiar en los valores predeterminados para esto es IMO malo.
Los nulos son solo eso: null s. Falta valor y un gran PITA cuando se trata de Three-Valued Logic.
un valor perdido es un valor en sí mismo ... hay muchos casos de uso donde "sin valor" conlleva un significado específico, sustituyendo "valores mágicos" (como -99999) en lugar de nulo no simplifica nada; o bien el código de consumo tiene que marcar "si X.HasValue()" o "si X == -99999". – STW
No sé por qué está incluso tratando de compararlos con los casos. null significa que alguna columna está vacía/no tiene ningún valor, mientras que el valor predeterminado otorga un valor a la columna cuando no la establecemos directamente en la consulta.
Quizás algún ejemplo sea una mejor explicación. Digamos que tenemos la tabla member. Cada miembro tiene una ID y un nombre de usuario. Opcionalmente, él podría tener una dirección de correo electrónico (pero él no tiene que hacerlo). Además, cada miembro tiene una columna postCount (que se incrementa cada vez que el usuario escribe una publicación). Entonces, la columna de correo electrónico puede tener un valor null (porque el correo electrónico es opcional), mientras que la columna postCount es NOT NULL, pero tiene el valor predeterminado 0 (porque cuando creamos un nuevo miembro no tiene ninguna publicación).
Porque no entiendo completamente el concepto de usar estos dos, gracias. –
Los valores NULL están destinados a indicar que el atributo no es aplicable o desconocido. Hay guerras religiosas peleadas por si son algo bueno o malo, pero caigo en el campo de las "cosas buenas".
A menudo son necesarios para distinguir valores conocidos de valores desconocidos en muchas situaciones y hacen innecesario un valor centinela para aquellos atributos que no tienen un valor predeterminado adecuado.
Por ejemplo, aunque el valor predeterminado para un saldo bancario puede ser cero, ¿cuál es el valor predeterminado para un número de teléfono móvil. Es posible que necesite distinguir entre "el cliente no tiene teléfono móvil" y "el número de teléfono móvil del cliente no es (todavía) conocido", en cuyo caso una columna en blanco no funcionará (y tendrá una columna adicional para decidir si esa columna es una o la otra no es una buena idea).
Los valores predeterminados son simplemente lo que el DBMS colocará en una columna si no se especifica explícitamente.
000-000-0000 o 555-555-5555 o cualquier otro número de teléfono no válido es un buen número de teléfono predeterminado, todo lo que puede probar es tan bueno como la prueba contra NULL en teoría, pero mucho más fácil en la práctica. –
No estoy de acuerdo, confuso. Lo que está usando es un centinela, un valor real falso para indicar metadatos sobre el campo. Hay casos en que todos los valores posibles son válidos y ninguno se puede usar como un centinela. Además, no es más difícil poner "es nulo" en sus consultas que "= '000-000-0000'" (y generalmente más espacio eficiente para almacenar el valor nulo) así que no estoy seguro de qué problema tiene con NULL eso lo hace más difícil. – paxdiablo
Los valores nulos no son ... valores!
nulo significa 'no tiene valor' ... junto al aspecto de la base de datos, una dimensión importante de variables o campos no valorados es que no es posible usar '=' (o '>', '<'), al comparar variables.
Escribiendo algo así como (VB):
if myFirstValue = mySecondValue
no volverá Verdadero o Falso si una o ambas de las variables son no valorado. Usted tendrá que utilizar un 'cambio de tendencia', tales como:
if (isnull(myFirstValue) and isNull(mySecondValue)) or myFirstValue = mySecondValue
El código 'habitual' utilizado en tales circunstancias es
if Nz(myFirstValue) = Nz(mySecondValue, defaultValue)
no es estrictamente correcto, ya que se tendrán en cuenta las variables no valorado como 'igual' al valor 'defaultValue' (generalmente cadena de longitud cero).
A pesar de este comportamiento desagradable, nunca nunca nunca encienda sus valores predeterminados en cadena de longitud cero (o '0's) sin una razón válida, y la comparación de valores de aceleración en el código no es una razón valiosa.
bueno para usted por afirmar que los NULL no son valores. –
Como con muchas cosas, hay puntos buenos y malos para cada uno.
Buenos puntos acerca de los valores predeterminados: le dan la capacidad de establecer una columna a un valor conocido si no se proporciona ningún otro valor. Por ejemplo, al crear columnas BOOLEAN normalmente le doy a la columna un valor predeterminado (VERDADERO o FALSO, lo que sea apropiado) y hago que la columna NO sea NULA. De esta manera, puedo estar seguro de que la columna tendrá un valor, y se establecerá de manera apropiada.
Puntos negativos sobre los valores predeterminados: no todo tiene un valor predeterminado.
Buenas cosas acerca de NULL: no todo tiene un valor conocido en todo momento. Por ejemplo, al crear una nueva fila que representa a una persona, es posible que no tenga valores para todas las columnas; digamos que sé su nombre, pero no su fecha de nacimiento. No es apropiado incluir un valor predeterminado para la fecha de nacimiento: a las personas no les gusta recibir tarjetas de cumpleaños el 1 de enero (si ese es el valor predeterminado) si su fecha de cumpleaños es realmente el 22 de julio.
Cosas malas acerca de NULL: NULLs requieren un manejo cuidadoso. En la mayoría de las bases de datos basadas en el modelo relacional ya que los NULL comúnmente implementados son venenos, la presencia de un NULL en un cálculo hace que el resultado del cálculo sea NULL. Los NULL utilizados en las comparaciones también pueden provocar resultados inesperados porque cualquier comparación con NULL devuelve UNKNOWN (que no es TRUE ni FALSE). Por ejemplo, considere la siguiente secuencia de comandos PL/SQL:
declare
nValue NUMBER;
begin
IF nValue > 0 THEN
dbms_output.put_line('nValue > 0');
ELSE
dbms_output.put_line('nValue <= 0');
END IF;
IF nValue <= 0 THEN
dbms_output.put_line('nValue <= 0');
ELSE
dbms_output.put_line('nValue > 0');
END IF;
end;
La salida del anterior es:
nValue <= 0
nValue > 0
Esto puede ser un poco sorprendente. Tiene un NÚMERO (nValor) que es menor o igual que cero y mayor que cero, al menos según este código. La razón por la que esto sucede es que nValue es en realidad NULL, y todas las comparaciones con NULL resultan en UNKNOWN en lugar de TRUE o FALSE. Esto puede dar lugar a errores sutiles que son difíciles de entender.
Comparte y disfruta.
Depende de la situación, pero en realidad es realmente simple. ¿Cuál está más cerca de la verdad?
Mucha gente maneja los datos como si fueran solo datos, y la verdad no importa. Sin embargo, cada vez que hablas con los interesados en los datos, encuentras que la verdad siempre importa. a veces más, a veces menos, pero siempre importa.
Un valor predeterminado es útil cuando puede presumir que si el usuario (u otra fuente de datos) había proporcionado un valor, el valor hubiera sido el predeterminado. Si esta presunción hace más daño que bien, entonces NULL es mejor, aunque lidiar con NULL es un problema en SQL.
Tenga en cuenta que hay tres formas diferentes de implementar los valores predeterminados. Primero, en la aplicación, antes de insertar nuevos datos. ¡La base de datos nunca ve la diferencia entre un valor predeterminado proporcionado por el usuario o uno provisto por la aplicación!
En segundo lugar, declarando un valor predeterminado para la columna y dejando los datos faltantes en una inserción.
Tercero, sustituyendo el valor predeterminado en el momento de la recuperación, siempre que se detecte un NULL. Solo unos pocos productos DBMS permiten declarar este tercer modo en la base de datos.
En un mundo ideal, los datos nunca faltan. Si se está desarrollando para el mundo real, eventualmente faltarán los datos requeridos. Sus aplicaciones pueden hacer algo que tenga sentido o algo que no tenga sentido cuando eso suceda.
Null s y los valores predeterminados son cosas diferentes que se usan para diferentes propósitos. Si está tratando de evitar el uso de null dando todo un valor predeterminado, esa es una práctica deficiente, como explicaré.
Null significa que no sabemos cuál es o será el valor. Por ejemplo, supongamos que tiene un campo enddate. No sabe cuándo terminará el proceso que se está grabando, por lo que null es el único valor apropiado; Usar un valor predeterminado de alguna salida de fecha falsa en el futuro causará tantos problemas para programar como manejar el null y es más probable que en mi experiencia cree un problema con la devolución de resultados incorrectos.
Ahora hay ocasiones en las que podemos saber cuál es el valor si la persona que inserta el registro no lo conoce. Por ejemplo, si tiene un campo date inserted, es apropiado tener un valor predeterminado de la fecha actual y no esperar que el usuario lo complete. Es probable que tenga mejor información de esa manera para este campo.
A veces, es una decisión y depende de las reglas comerciales que debe aplicar. Supongamos que tiene un campo speaker honoraria (que es la cantidad que pagaría un hablante). Un valor predeterminado de 0 podría ser peligroso, ya que podría significar que los hablantes están contratados y no tenemos la intención de pagarles nada. También es posible que ocasionalmente haya oradores que donen su tiempo para un proyecto en particular (o que sean empleados de la empresa y por lo tanto no paguen más por hablar) donde cero es un valor correcto, por lo que no puede usar cero como el valor para determinar que usted no sabe cuánto se le pagará a este orador. En este caso, Null es el único valor apropiado y el código debería desencadenar un problema si alguien intenta agregar el altavoz a una conferencia. En una situación diferente, ya sabrá que el mínimo que se pagará a un hablante es 3000 y que solo los hablantes que hayan negociado una tarifa diferente tendrán los datos ingresados en el campo honoraria. En este caso, es apropiado poner un valor predeterminado de 3000. En otros casos, diferentes clientes pueden tener diferentes mínimos, por lo que el valor predeterminado debe manejarse de manera diferente (generalmente a través de una tabla de búsqueda que rellena automáticamente el valor mínimo honoraria para ese cliente en el formulario de entrada de datos.
Así que siento la mejor regla es dejar el valor como null si realmente no puede saber en el momento en que se ingresan los datos cuál debe ser el valor del campo.Use un valor predeterminado, solo tiene significado todo el tiempo para esa situación en particular y use alguna otra técnica para completar el valor si pudiera ser diferente bajo diferentes circunstancias.
En un almacén de datos, siempre desearía tener valores predeterminados en lugar de valores NULL.
En su lugar tendría valor como "desconocido", "no está listo", "perdido"
Esto permite combinaciones internas a realizar de manera eficiente en el hecho y tablas de dimensiones como 'todo siempre tiene un valor'
Como ya dijo un respondedor, NULL no es un valor.
Sé muy consciente de cualquier cosa proclamada por cualquiera que hable de "valor NULO" como si fuera un valor.
NULL no es igual a sí mismo. x = y produce falso si tanto x como y son NULL. x = y produce verdadero si tanto x como y son el valor predeterminado.
Hay consecuencias casi infinitas para esta diferencia aparentemente muy simple. Y la mayoría de esas consecuencias son trampas explosivas que te pican muy mal.
Dos muy buenos artículos de acceso orientado-unos valores nulos de Allen Browne:
aspectos del trabajo con valores nulos en código VBA:
Los artículos están orientados al acceso, pero podrían ser valiosos para quienes usan cualquier base de datos, particularmente los novatos relativos debido al estilo de conversación de la escritura.
Nulos NUNCA guarde el espacio de almacenamiento en DB2 para OS/390 yz/OS. Cada columna que admite nulos requiere un byte de almacenamiento adicional para el indicador nulo. Por lo tanto, una columna CHAR (10) que puede contener nulos requerirá 11 bytes de almacenamiento por fila: 10 para los datos y 1 para el indicador nulo. Este es el caso independientemente de si la columna está configurada como nula o no.
DB2 para Linux, Unix y Windows tiene una opción de compresión que permite que las columnas establecidas en nulo ahorren espacio. Al usar esta opción, DB2 elimina el espacio no utilizado de una fila donde las columnas se establecen como nulas. Sin embargo, esta opción no está disponible en el mainframe.
REF: http://www.craigsmullins.com/bp7.htm
Por lo tanto, la mejor práctica de modelado para DB2 z/OS es el uso de "NOT NULL WITH DEFAULT" como un estándar para todas las columnas. Es lo mismo seguido en algunas tiendas importantes que conocí. Hace que la vida de los programadores sea más fácil ya que no tiene que manejar el Indicador nulo y, en realidad, ahorra almacenamiento al eliminar la necesidad de usar el byte adicional para el INDICADOR NULO.
Aprecio mucho esta discusión. Estoy en medio de la construcción de un almacén de datos y estoy usando el modelo de Kimball bastante estrictamente. Sin embargo, hay un usuario muy vocal que odia las claves sustitutas y quiere valores NULL por todas partes.Le dije que está bien tener columnas NULLable para atributos de dimensiones y para cualquier fecha o número que se usen en los cálculos porque los valores predeterminados allí implican datos incorrectos. Hay, estoy de acuerdo, ventajas de permitir NULL en ciertas columnas, pero hace que el cubing sea mucho mejor y más confiable si hay una clave sustituta para cada clave foránea de una dimensión, incluso si ese sustituto es -1 o 0 para un registro ficticio . SQL le gusta los enteros para las uniones y si hay un valor de dimensión faltante y se proporciona un maniquí como una clave sustituta, obtendrá la misma cantidad de registros usando una dimensión que cubing en otra dimensión. Sin embargo, los cálculos deben hacerse correctamente y debe acomodarse a los valores NULL en esos. El cumpleaños debe ser NULO para que la edad no se calcule, por ejemplo. Creo en una buena gobernanza de datos y tomar estas decisiones con los usuarios los obliga a pensar en sus datos de más formas que nunca.
tener valores predeterminados hace que las instrucciones WHERE sean portátiles en las bases de datos, existen múltiples formas de manejar NULL. Si tiene un valor predeterminado, puede probarlo igual que cualquier otro valor con = en lugar de tener que hacer IS/IS NOT. –