¿Es una buena idea usar una columna calculada como parte de una clave principal?

Question

Tengo una tabla definida como:

OrderID bigint NOT NULL, 
IDA varchar(50) NULL, 
IDB bigint NULL, 
[ ... 50 other non relevant columns ...] 

La clave principal natural para esta tabla sería (IdPedido, AIF, BID), pero esto no es posible debido a la AIF y el BID pueden ser nulos (que pueden ambos son nulos, pero nunca son ambos definidos al mismo tiempo). En este momento tengo una restricción única en esas 3 columnas.

Ahora, la cosa es que necesito una clave principal para permitir la replicación transaccional, y yo estoy frente a dos opciones:

• Crear una columna de identidad y lo utilizan como una clave primaria
• Crear una columna C no calculada nula que contiene IDA o IDB o '' si ambas columnas son nulas, y uso (OrderID, C) como mi clave principal.

Las segundas costuras alternativa más limpia como mi PK sería significativo, y es factible (ver msdn link), pero ya que nunca he visto este hecho en cualquier lugar, me preguntaba si había algunas desventajas de este enfoque.

Answer 1

Las columnas, que pueden ser nulas no califican como parte de un pk, porque un pk también debe ser único.

También una PK nunca debe ser significativa, porque el significado de un valor puede cambiar.

¿La tabla A y B tiene una relación? Mira el modelo de datos relacionales. Puede haber un error en el diseño.

OrderID debe ser único y, por lo tanto, suficiente para un PK.