¿Una mala práctica de clave externa anulable?

Supongamos que tiene una tabla Pedidos con una clave externa a un ID de cliente. Ahora, suponga que desea agregar un pedido sin un ID de cliente, (si eso debería ser posible es otra pregunta), tendría que hacer que la clave externa sea NULL ... ¿Es una mala práctica o prefiere trabajar con una tabla de enlaces entre Pedidos y Clientes? Aunque la relación es de 1 an, una tabla de vínculos la convertiría en n an. Por otro lado, con una tabla de enlaces, ya no tengo esos NULLS ...

En realidad, no habrá muchos NULL en la base de datos, porque un registro con una clave externa a NULL es solo temporalmente hasta que se agrega un cliente para el pedido.

(En mi caso no es un Pedido y un Cliente).

EDITAR: ¿Qué pasa con un Cliente no asignado para vincular?

Tener la tabla de enlaces es probablemente una mejor opción. Al menos no viola la normalización BCNF (forma normal de Boyce-Codd). sin embargo, preferiría ser pragmático. Si tiene muy pocos de estos valores nulos y son solo temporales, creo que debería omitir la tabla de enlaces, ya que solo agrega complejidad al esquema.

En otros comentarios; el uso de una tabla de enlaces no necesariamente lo convierte en n an, si en la tabla de enlaces usa la clave externa que apunta a su tabla de pedidos como la clave principal en esa tabla de enlaces, la relación sigue siendo 1..n. Solo puede haber una entrada en esa tabla de enlaces por pedido.

No No hay nada de malo con los FK que aceptan valores NULL. Esto es común cuando la entidad a la que apunta FK está en una relación (de cero o uno) a (1 o muchos) con la tabla de referencia de la clave principal.

Un ejemplo podría ser si tuviera una dirección física y un atributo (columna) de dirección postal en una tabla, con FK en una tabla de direcciones. Puede hacer que la dirección física sea anulable para manejar cuando la entidad solo tenga un apartado de correos (dirección postal) y la dirección postal sea anulable para manejar cuando la dirección postal sea la misma que la dirección física (o no).

Las columnas que aceptan valores NULL pueden estar en 1NF a 5NF, pero no en 6NF según lo que he leído.

Solo si sabes mejor que Chris Date "lo que realmente significa la primera forma normal". Si xey son ambos anulables, y de hecho en alguna fila xey son ambos null, entonces WHERE x=yno cede true. Esto prueba más allá de toda duda razonable que nulo no es un valor (porque cualquier valor real es siempre igual a sí mismo). Y dado que la RM prescribe que "debe haber un valor en cada celda de una tabla", cualquier cosa que posiblemente contenga nulos, no es una cosa relacional, y por lo tanto la cuestión de 1NF ni siquiera surge.

He oído decir que las columnas que aceptan valores NULL en general rompen el primer grado de normalización.

Consulte más arriba la sólida razón que subyace a ese argumento.

Pero en la práctica es muy práctico.

Solo si eres inmune a los dolores de cabeza que suele provocar en todo el resto del mundo. Uno de esos dolores de cabeza (y es solo uno menor, en comparación con otros nullfenómenos) es el hecho de que WHERE x=yen SQL realmente significaWHERE x is not null and y is not null and x=y , pero que la mayoría de los programadores simplemente no son conscientes de ese hecho y simplemente lo leen. A veces sin ningún daño, otras veces no.

De hecho, las columnas que aceptan valores NULL violan una de las reglas de diseño de bases de datos más fundamentales: no combine elementos de información distintos en una columna. Los nulos hacen exactamente eso porque combinan el valor booleano "este campo está / no está realmente presente" con el valor real.

No veo nada de malo en que sea solo una relación n-1 opcional que se representará con un nulo en la clave externa. De lo contrario, si coloca su tabla de enlaces, tendrá que gestionar que no se convierta en una relación nn, lo que provocará aún más problemas.

Las relaciones opcionales son definitivamente posibles en el modelo relacional.

Puede utilizar valores nulos para expresar la ausencia de una relación. Son convenientes, pero le causarán los mismos dolores de cabeza que los nulos le causan en otros lugares. Un lugar donde no causan ningún problema son las uniones. Las filas que tienen un valor nulo en la clave externa no coinciden con ninguna fila de la tabla a la que se hace referencia. Así que abandonan una unión interna. Si realiza uniones externas, de todos modos tendrá que lidiar con nulos.

Si realmente desea evitar nulos (sexta forma normal), puede descomponer la tabla. Una de las dos tablas descompuestas tiene dos columnas de clave externa. Una es la clave externa opcional que tiene y la otra es una clave externa que hace referencia a la clave principal de la tabla original. Ahora tiene que usar restricciones para evitar que la relación se convierta en muchos a muchos, si quiere evitar eso.

Usar NULL sería una buena manera de limpiar pedidos incompletos:

SELECT * FROM `orders`
WHERE `started_time` < (UNIX_TIMESTAMP() + 900) AND `customer_id` IS NULL

Lo anterior mostraría pedidos de más de 15 minutos sin una identificación de cliente relacionada.

Si solo está agregando el pedido temporalmente sin identificación de cliente hasta que se defina un cliente, ¿no sería más sencillo agregar el cliente y el pedido en una sola transacción, eliminando así la necesidad de la entrada de clave externa NULL y evitando cualquier restricción o desencadenante? has configurado para ser violado?

Normalmente esta situación se presenta en aplicaciones web donde se detalla el pedido antes de que el cliente defina quién es. Y en esas situaciones, el pedido se mantiene en el estado del servidor o en una cookie hasta que se proporciona todo el estado necesario para un pedido completo, momento en el que el pedido se conserva en la base de datos.

Las claves externas NULL están bien para cosas como direcciones, como se mencionó anteriormente. Pero un campo de cliente NULO no tiene sentido para un pedido y debe estar limitado.

Siempre puede agregar una fila artificial a su tabla de Clientes, algo como Id = -1 y CustomerName = 'Desconocido' y luego, en los casos en que normalmente establecería su CustomerId en Order NULL, configúrelo en -1.

Esto le permite no tener FK que aceptan valores NULL, pero aún así representar la falta de datos de manera adecuada (y evitará que los usuarios posteriores no sepan cómo lidiar con los NULL).

Los FK que aceptan valores NULL para relaciones opcionales de varios a uno están totalmente bien.

He escuchado argumentar que las columnas que aceptan valores NULL en general rompen el primer grado de normalización. Pero en la práctica es muy práctico.

Sí, hay algo mal. No es una clave externa si es anulable. Su diseño de base de datos por código. Quizás hagas un enlace cero a no asignado. o "Sin asignar" si estás usando un carácter col. Mantenga la integridad de sus datos al 100%.