SQL Server - Discusion: Relaciones en SQL Server

Estimados, quiero iniciar una discusión acerca de Integridad de Datos y Relaciones en SQL Server 2000.
Un experimentado amigo y yo hemos discutido desde hace unos días acreca de este tema y hemos decidido acudir a este foro para obtener opiniones externas.
Se trata de lo siguiente:
Supongamos que en SQL Server 2000 tú tienes 2 tablas relacionadas, por ejemplo, Ventas y Clientes.
La relación la haces por el Codigo de Cliente de ambas tablas. Para exigir Integridad Referencial, exiges 'Relación para duplicación' y 'Exigir Relación para INSERT y UPDATE'. Hasta ahora todo bien. Continúo.
La regla de negocio indica que puedes realizar ventas sin necesidad de establecer el Cliente al que se estás vendiendo, lo que indica que nuestra relación debe permitir, o dejar el campo Nulo, o crear un cliente 0=Ninguno en Clientes y seleccionar éste cada vez que se realice una venta sin cliente.
Para mí, lo óptimo es establecer que el campo Codigo_Cliente en la tabla Ventas acepte nulos, guardandolo NULL cada vez que se realice una venta sin cliente, y manteniendo, claro, la relación para las validaciones correspondientes. Para mi amigo, en cambio, esto NO es Integridad referencial ni Integridad de Datos, y prefiere crear el cliente 0=Ninguno.
Espero sus comentarios. Gracias.

Tu amigo tiene razon, para conservar la integridad referencial de tus datos es necesario que en tus compos de relación no existan nulos, si checas un poco la teoria de relacion de conjuntos veras que es mejor y mas optimo hace los que tu ami comenta

Personalmente salvo casos en que las relaciones sean identificativas (que formen parte de la clave primaria) no suelo crear los registros como "Ninguno","No aplicable","Sin datos" etcétera. Ya que si dentro de vistas o procedimientos quieres saber en tu caso las ventas sin cliente definido harás un SELECT ... WHERE Cliente IS NULL de otra forma siempre "hardcodeas" el código "0" o "Ninguno"

Las relaciones tienen dos atributos: cardinalidad (uno, muchos) y minimalidad (uno, muchos, ninguno) las relaciones identificativas nunca pueden contener nulos porque forman parte de la clave primaria, si pueden contenerlos las no identificativas.

Integridad Referencial y de datos no tiene que ver con crear un registro con "Ninguno" ya que si una venta no tiene cliente definido sencillamente no lo tiene y no tiene más misterio.

En lo personal me manejo así y no he tenido problemas, ya que no soy muy amiga de los "códigos forzosos".

Gracias por tu opinión. Creo que te manejas super bien ya que tu argumento me pareció absolutamente válido.
Para mí, de hecho, 'harcodear' (o administrar códigos 'en duro') no es una buena práctica de desarrollo ya que si tu aplicación va a reemplazar o actualizar a otra y en esta se utiliza sólo uno de tus códigos 'en duro' (por ejemplo, 0 = Cliente 1), tu aplicación simplemente fracasa y entrar a modificar podría ser un parto. Sin embrago, el null siempre va a ser null.
De todas maneras, gracias por la molestia.

De nada, espero que aparezcan otras opiniones y que finalmente nos cuentes como siguió la cuestión.

Yo soy partidario de la utilizacion de Cliente 0 en la tabla Ventas, y utilizar siempre lo menos posible el valor NULL por los siguientes motivos:

1- Al utilizar NULL cometemos una PERDIDA DE INFORMACION, ya que el valor de NULL es que no existe relación, por tanto cualquier programador podria interpretar que no existe conexión con la tabla clientes. Y no es cierto por que la entidad Cliente Ninguno existe!

2- Si tratamos de crear un indice único o clave, utilizando el campo cod_Cliente (por ejemplo podriamos crear una indice con los campos cod_Cliente y nºpedido por cliente, no seria válido si cod_Cliente contiene valores NULL). Crear un indice no es ninguna tonteria porque optimiza consultas/Tablas.

3- Un caso práctico queremos insertar una Venta antes del cliente, podemos utilizar el valor NULL como comodin.

Toda esta opinion es siempre desde el punto de vista de Integridad Referencial de las base de datos, luego en la práctica todo cambia y evidentemente, es dificil cumplir los requisitos

javi

Vamos a ver,

Parece que teneis dificultades para discernir entre los conceptos de "Integridad referencial" y "relaciones". La relacion que comentas entre ventas y clientes esta perfectamente definida. Las cardinalidades serian

Ventas(0,1)-Clientes(0,N)

es decir una venta puede estar asociado con cero o mas clientes y a un cliente pueden haberle vendido cero 0 mas "ventas".

La relacion ES LA QUE ES y debe ser modelada tal y como es y el modelo relacional debe ser un reflejo del modelo entidad-relacion para que pueda llevarse a cabo una Normalizacion correcta.

Para soportar este tipo de relaciones los gestores de bases de datos integran el tipo NULL. ¡NO HAY NINGUN PROBLEMA EN ESTO y yo diria mas, para que el modelo relacional comprenda este tipo de relaciones ES NECESARIO!.

La integridad referencial se refiere a que tras las operaciones tipicas de gestion de entidades o tablas los datos contenidos deben ser coherentes con el modelo propuesto. Esto es, si tenemos una venta asociada a un cliente X y pretendemos borrar este cliente X , provocaremos un error de Integridad referencial ya que nuestro modelo relacional exige que ese cliente exista en la otra tabla, pero esto es INDEPENDIENTE de si una venta puede estar asociada o no con un cliente ya que esto lo expresamos cuando construimos el modelo relacional.

Todavia iria aun mas lejos, no ya con problemas a la hora de normalizar (el mero hecho de tener un registro que representa una relacion inexistente entre dos registros de tableas rompe con el modelo relacional) sino a la hora de gestionar esto pueden surgir numerorsos problemas.

Asi pues, como resumen, que me enrollo mucho, no mezclar temas de modelizar relaciones con los temas de integridad referencial y como final decir que tu amigo no esta en lo correcto.

Un saludo.

100% de acuerdo, una cosa son las RELACIONES, como bien lo explicas y otra muy diferente el DRI.

Por eso dije, antes de leer los demas comentarios, si se busca DRI, el "amigo" esta en lo cierto, si no, con una simple ralacion cumple con el requisito, no habiendo DRI

Saludos.

Sin leer los demas comentarios, estoy 100% de acuerdo con tu AMIGO, es preferible dar de alta un codigo 0 = Ninguno o bien 0 = Venta Mostrador, eso si es DRI.

Saludos.