Ver Mensaje Individual
  #5 (permalink)  
Antiguo 11/10/2011, 19:07
Avatar de matanga
matanga
 
Fecha de Ingreso: octubre-2007
Ubicación: España
Mensajes: 1.091
Antigüedad: 16 años, 6 meses
Puntos: 85
Respuesta: error al crear el diagrama de base de datos

También soy de la opinión que es importante dedicar tiempo para analizar el tipo de dato que corresponde a cada columna, hace tiempo pasé por la experiencia de trabajar con modelos que tenían una definición incorrecta y pude apreciar consecuencias como:

1. Bajo rendimiento. Es común el caso de campos tipo varchar para almacenar fechas y que además tengan un índice porque se utilizan como filtro. Los problemas de rendimiento vienen cuando se necesita comparar el valor como tipo fecha, por ejemplo: where cast(campo as date) = getdate(), ya que una función aplicada al campo evita el uso del índice. Y por otro lado, el optimizador puede generar un mal plan de ejecución en casos donde contempla los posibles valores de una columna, como por ejemplo, la cantidad de valores posibles entre '20101231' y '20110101', donde el resultado en el tipo varchar es diferente al tipo datetime.

2. Almacenamiento. El espacio necesario para guardar un valor dado puede variar en función del tipo de dato, pero el consumo es óptimo si se respeta cada tipo, por ejemplo: para almacenar la fecha '20101231' se requieren 8 bytes en el tipo datetime y 10 bytes en el tipo varchar, este ahorro de 2 bytes se aprecia en bases de datos grandes tipo data warehouse.

3. Codificación de consultas. Si los tipos no son correctos, es probable que se necesiten funciones de conversión en las consultas para poder tratar los valores, esto genera código innecesario además de incrementar la dificultad de comprensión. Es preferible escribir y leer where campo = getdate() en vez de where cast(campo as date) = getdate() .

Dicho esto, el error "the following data type properties of column..." se da cuando se quiere relacionar una columna foreign key con otra columna primary key o unique pero de distinto tipo. Para el caso particular que planteas, la diferencia de tipos entre la FK y PK no parece una mala definición, diría que el problema es que la relación entre detalle_recepcion.cantidad_recepcionada y clientes.nombres es inválida porque cada columna representa un concepto distinto.

Saludos