Czy warto używać kolumny obliczeniowej jako części klucza podstawowego?

Question

Mam tabeli zdefiniowane jako:

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

Naturalna klucz podstawowy dla tabeli byłaby (OrderID, IDA, IDB), ale to nie jest możliwe, ponieważ IDA i IDB może być null (mogą one oba są zerowe, ale nigdy nie są zdefiniowane w tym samym czasie). W tej chwili mam unikalne ograniczenie dla tych 3 kolumn.

Teraz chodzi o to, muszę mieć klucz podstawowy, aby umożliwić replikacji transakcyjnej, i mam do czynienia z dwóch opcji:

• Załóż kolumny tożsamości i użyć go jako klucz podstawowy
• Tworzenie niezerowa kolumna C zawierająca IDA lub IDB lub ", jeśli obie kolumny mają wartość zerową i jako mój klucz podstawowy użyję (OrderID, C).

Drugi szwy alternatywne czystsze jak mój PK byłoby sensowne, a jest to możliwe (patrz msdn link), ale ponieważ nigdy nie widziałem to zrobić w dowolnym miejscu, zastanawiałem się, czy były jakieś minusy do tego podejścia.

Answer 1

Kolumny, które mogą mieć wartość null, nie kwalifikują się jako część pakietu pk, ponieważ element pk musi być unikalny.

Również PK nigdy nie powinno mieć znaczenia, ponieważ znaczenie wartości może się zmienić.

Czy tabela A i B mają związek? Spójrz na model danych relacyjnych. W projekcie może być błąd.

Identyfikator zamówienia powinien być niepowtarzalny, a zatem wystarczający dla PK.