4 respuestas en este tema

[JRichard]

Saludos.

Quisiera saber que recomiendan en cuanto al uso de valores nulos en una tabla dentro de una base de datos. Se que el valor NULL se usa para aquellos campos que en algún momento no almacenen ningún valor.

Ahora, supongamos que tengo una tabla con los campos CODIGO, NOMBRE Y TELEFONO, por lógica el código y el nombre serían obligatorios o sea NOT NULL, a diferencia del campo TELEFONO que no es un campo obligatorio.

Ok, desde un formulario en delphi ingreso estos valores a la tabla en mi base de datos:

Código: 1
Nombre: Juan
Teléfono:

Lógicamente se almacenaran los valores CODIGO = 1, NOMBRE = Juan Y TELEFONO = "" en mi base de datos, y a este punto es el que quería llegar. Como no le estoy pasando valores al campo TELEFONO en mi base de datos se almacena "" que no es lo mismo que decir NULL.

Entonces, quisiera saber si para optimizar las consultas hacia una base de datos al momento de guardar un campo que pueda tener valores nulos es conveniente enviar el valor NULL o dejar el campo vacío.

Adjunto dejo una imagen para que me entiendan mejor.

En esta muestro parte de una tabla, la cual tiene un campo llamado OBSERVACION, este campo puede o no almacenar valores ya que no es obligatorio y por DEFAULT mediante un DOMINIO hago que se guarde el valor <null> o sea que si al momento de insertar o modificar no hago mención a este campo el valor por defecto sería <null>. Pero también se observa que existe un registro que tiene en el campo OBSERVACION el valor "", este registro lo inserte desde un formulario.

Y pues mi interés es saber si al momento de almacenar datos en un campo que acepte valores nulos y no le pase valores, es mejor enviar a la base de datos el valor NULL o el campo vacío. 

Archivos adjuntos

•  4552_72a886d2bf44aa940e1ec15843f3d7a22cfe9106.png   14,32KB   7 descargas

[egostar]

Hola,

Desde mi punto de vista, los únicos campos que podrían contener un valor nulo serían los campos de tipo string, los demás no debería permitir contener valores nulos ya que provocan excepciones durante su manejo y obligan a escribir validaciones fastidiosas.

Saludos

[cram]

Prefiero usar los valores NULL.
¿Para qué asignarías un valor inutil?, es decir el valor NULL significa no asignado, por lo que es útil para saber que ese campo es virgen. Si, le asignas un valor inútil como "" estarías perdiendo una utilidad de los nulos.
Por ejemplo, yo utilizo la consulta por valores NULL para saber si se pagó una cuota preguntando por si el día de pago está asignado (no es el mejor ejemplo ya que mi implementación es bastante extraña), pero creo que puedes entenderlo.
Por otra parte, si obligas a asignar un valor al nombre de una persona, y luego le asignas "" esto es lícito y exigirá una comprobación extra para saber si la fila tiene un nombre "normal", mientras que utilizando NULL, puedes asegurarte de conocer cuando un nombre no fue asignado.
Cuando asignas un valor vacío a un campo de tipo CHAR, desperdicias el total del tamaño de ese campo, mientras que utilizando un campo VARCHAR solo desperdicias el tamaño mínimo (creo que es integer), por lo que no es lo mismo [en cuestión de espacio] asignar vacío a una variable CHAR(10) que dejarlo nulo.
Otro uso en el que puedes permitirte los nulos es cuando no quieres eliminar las entidades ligadas a una referencia, cuando se procedería a una eliminación por cascada. O sea, cuando no realizas la eliminación por cascada y dejas nulo el valor de la clave foránea.
Otro ejemplo, cuando tienes un campo día de nacimiento y el operador no puede proveerlo. Suponiendo que la edad se calcula a partir de este valor, no es conveniente asignarle un valor fijo.
En el caso de las observaciones, es posible hacer que el gestor de reportes detecte los nulos y escriba en su lugar "NO APLICADO", "N/A", o algo parecido. O en su defecto en las vistas utilizando coalesce.
En otras palabras vivan los NULLS. Te dan miles de oportunidades de control sobre los datos.
Para comprenderlos mejor, asimílalos como NIL de pascal.

[Delphius]

Para solucionar el problema de porqué te graba el "" y no el NULL debes hacer dos cosas:
1) Declarar el campo para que por defecto asuma NULL. Para esto solo hace falta que añadas la cláusula DEFAULT NULL.
2) Al momento de hacer el INSERT no pases ni indiques los campos a ser nulos. El motor asumirá que al no ser pasados en el INSERT se está por almacenar el valor por defecto. Es decir que si tienes algo como:

sql

INSERT INTO TABLA1 (CODIGO, NOMBRE, OBSERVACION) VALUES (:PARAM1, :PARAM2, :PARAM3);

Y el campo Observación es nulo, entonces la consulta queda en:

sql

INSERT INTO TABLA1 (CODIGO, NOMBRE) VALUES (:PARAM1, :PARAM2);

El motor ya se encargará del trabajo.

Aunque también se puede hacer esto:

sql

INSERT INTO TABLA1 (CODIGO, NOMBRE, OBSERVACION) VALUES (123, 'Juan', NULL);

Y si empleas parámetros para pasar el valor, como en el primer ejemplo, puedes pasarle el valor null al parámetro indicándole que dicho campo sea Null por medio de la propiedad IsNull. Aunque esto también depende de los componentes que empleas para conectarte.

Firebird además permite indicar en un INSERT indicarle formalmente que se asuma el valor por defecto. Mira en este artículo sobre el tema.

Saludos,

[JRichard]

Saludos a todos, gracias por responder y pues ahora me queda más claro el como usar el NULL.

Y pues al igual que cram me inclino un poco más por el valor NULL en aquellos campos donde no existan datos a diferencia de dejarlo vacío . Aunque me he leído varios artículos de optimización de base de datos y muchos recomiendan en la medida de lo posible no usar campos NULL, ya que estos ralentizan un poco la respuesta de las consultas,  pero es algo inevitable no creo que exista una base de datos en el mundo que tenga tablas donde no existan campos NULL. La idea sería no excederse en su uso pero es casi que imposible no tener un campo NULL en una tabla dentro de una base de datos. 

Si los campos NULL existen es por algo, y supongo que al manejador de base de datos se le hace más fácil trabajar con campos NULL que dejar un campo "" (vacío) ya que esto (como explica cram) implica una validación en cambio al detectar un campo con un valor NULL lo ignora completamente y retorna NULL para ese campo. Además desde el punto de vista de un diseñador o analista de sistemas no estaría bien visto guardar campos "" en ves de NULL. El valor NULL implica más trabajo más validaciones pero este trabajo rendirá frutos al momento de tener un jefe experto en la materia. No es lo mismo vender una aplicación a un cliente al cual se le puede engañar fácilmente que trabajar para una persona que conozca sobre análisis y diseño de sistemas. La calidad de trabajo (Además de muchas cosas) es lo que hace la diferencia entre un programador y otro. Tal vez no estoy en lo correcto pero es la conclusión que saco gracias a sus comentarios.

Delphius, estoy utilizando parámetros para pasar el valor como el primer ejemplo que colocaste. Le estoy pasando el valor NULL al parámetro indicándole que dicho campo es NULL por medio de la propiedad IsNull pero este método me genera una excepción. Los componentes que estoy utilizando son el TSQLConnetion y el TSQLQuery.