È una buona idea usare una colonna calcolata come parte di una chiave primaria?

Question

Ho una tabella definita come:

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

La chiave primaria naturale per questo tavolo sarebbe (OrderID, IDA, IDB), ma questo non è possibile perché IDA e IDB possono essere null (che possono entrambi sono nulli, ma non sono mai entrambi definiti allo stesso tempo). In questo momento ho un vincolo univoco su quelle 3 colonne.

Ora, la cosa è ho bisogno di una chiave primaria per abilitare la replica transazionale, e sono di fronte a due scelte:

• Creare una colonna di identità e usarlo come una chiave primaria
• Creare un colonna calcolata non nullo C contenente IDA o IDB o "" se entrambe le colonne erano nulle e utilizzare (OrderID, C) come chiave primaria.

Il secondo cuciture un'alternativa più pulita come il mio PK sarebbe significativo, ed è fattibile (vedi msdn link), ma dal momento che non ho mai visto questo fatto ovunque, mi chiedevo se fossero alcuni svantaggi di questo approccio.

Answer 1

Le colonne, che possono essere nulle, non si qualificano come parte di un pk, perché anche un pk deve essere univoco.

Anche un PK non dovrebbe mai essere significativo, perché il significato di un valore potrebbe cambiare.

Le tabelle A e B hanno una relazione? Guarda il modello dei dati relazionali. Potrebbe esserci un errore nel design.

OrderID deve essere univoco e quindi sufficiente per un PK.