example - SQL: usar valores NULL vs. valores predeterminados
sql server migration assistant for access (13)
Un valor NULL en las bases de datos es un valor del sistema que ocupa un byte de almacenamiento e indica que un valor 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 es desconocido al momento de mirarlo. Una columna que permite valores NULOS también permite insertar filas sin ningún valor en esa columna. Existen varios pros y contras de utilizar valores NULL en comparación con los valores predeterminados:
Pros
El valor NULL no tiene el tipo de datos, por lo tanto, se puede insertar en cualquier estructura de datos y cualquier columna de base de datos. Por otro lado, los valores predeterminados deben tener su tipo de datos especificado y un valor predeterminado en una columna puede tener el mismo aspecto en otra columna, pero puede ser de un tipo diferente.
NULL se usa 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 el almacenamiento de valores negativos en un campo entero para representar datos omitidos.
Dado que el valor NULL ocupa solo 1 bit de espacio de memoria, pueden ser útiles al optimizar la base de datos. Usar esos valores es mucho más eficiente que los valores predeterminados, por ejemplo, los 8 bits del personaje y los 16 bits del número entero.
Si bien los requisitos de su sistema pueden cambiar con el tiempo y los tipos de valores predeterminados con ellos, el valor NULL siempre es NULO, por lo que no es necesario actualizar el tipo de datos.
Asignar No nulo a esquemas de tabla también puede ayudar con la validación de tabla, en un sentido que la columna con criterios No nulo requerirá que se inserte un valor. Los valores predeterminados no tienen estas capacidades.
Contras
Los valores NULL se confunden fácilmente con cadenas de caracteres vacías, que devuelven un valor en blanco al usuario cuando se lo selecciona. En este sentido, los valores predeterminados son menos confusos y son la opción más segura, a menos que el valor predeterminado se establezca en la cadena vacía.
Si se permiten valores NULL en la base de datos, pueden ocasionarle al diseñador más tiempo y trabajo, ya que pueden complicar aún más la lógica de la base de datos, especialmente cuando existen muchas comparaciones con valores nulos.
Fuente: Pro y contras
¿Cuáles son los pros y los contras de utilizar valores NULL en SQL en comparación con los valores predeterminados ?
PD. Se han hecho muchas preguntas similares aquí pero ninguna responde mi pregunta.
Aprecio mucho toda 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.
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.
Lo bueno de NULLs: 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.
Lo malo de NULL: NULL requiere 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;
El resultado de lo 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.
Como ya dijo un respondedor, NULL no es un valor.
Sea muy amigo 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.
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 suponer que si el usuario (u otra fuente de datos) hubiera 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, al declarar un valor predeterminado para la columna y dejar los datos faltantes en una inserción.
En tercer lugar, 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.
Dos muy buenos artículos orientados al acceso sobre Nulls por Allen Browne:
Aspectos de trabajar con nulos en el 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.
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 listo", "perdido"
Esto permite que INNER JOINs se realice de manera eficiente en las tablas de Hecho y Dimensión ya que ''todo siempre tiene un valor''
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 que un valor centinela sea innecesario 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 lo especifica explícitamente.
Los valores nulos no son ... valores!
Nulo significa ''no tiene valor'' ... además del aspecto de la base de datos, una dimensión importante de las variables o campos no valorados es que no es posible usar ''='' (o ''>'', ''<'') al comparar variables.
Escribir algo como (VB):
if myFirstValue = mySecondValue
no devolverá True o False si una o ambas variables no son valoradas. Deberá usar un ''cambio'' como, por ejemplo:
if (isnull(myFirstValue) and isNull(mySecondValue)) or myFirstValue = mySecondValue
El código ''usual'' utilizado en tales circunstancias es
if Nz(myFirstValue) = Nz(mySecondValue, defaultValue)
No es estrictamente correcto, ya que las variables no valoradas se considerarán como ''iguales'' al valor ''defaultValue'' (generalmente cadena de longitud cero).
A pesar de este comportamiento desagradable, nunca nunca encienda sus valores predeterminados en una cadena de longitud cero (o "0") sin una razón valiosa, y la comparación de valores de aceleración en el código no es una razón valiosa.
Nulos NUNCA guardan espacio de almacenamiento en DB2 para OS / 390 y z / 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 usar "NOT NULL WITH DEFAULT" como 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.
Para mí, son algo ortogonales.
Los valores predeterminados le permiten evolucionar con gracia 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 la lógica de tres valores.
Null valores Null y predeterminados son cosas diferentes que se usan para diferentes propósitos. Si está tratando de evitar el uso de null s dando a 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 de fecha de 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 null y es más probable que en mi experiencia cree un problema con la devolución de resultados incorrectos.
Ahora hay ocasiones en que podemos saber cuál es el valor si la persona que inserta el registro no lo hace. Por ejemplo, si tiene un campo de 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 esta manera para este campo.
A veces, es una decisión y depende de las reglas comerciales que debe aplicar. Supongamos que tiene un campo de speaker honoraria (que es la cantidad que se le pagaría a un orador). Un valor predeterminado de 0 podría ser peligroso, ya que podría significar que los oradores son 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 orador 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 datos ingresados en el campo de 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 se debe manejar de manera diferente (generalmente a través de una tabla de búsqueda que rellena automáticamente el valor mínimo de honoraria para ese cliente en el formulario de entrada de datos).
Por lo tanto, creo que 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.
No sé por qué estás tratando de comparar estos 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 una tabla de 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 NOT NULL ES NULA, pero tiene el valor predeterminado 0 (porque cuando creamos un nuevo miembro no tiene ninguna publicación).