Poprawna jest odpowiedź dotycząca klucza głównego, bo to właśnie pole (lub zestaw pól) oznaczone jako PRIMARY KEY w tabeli pełni rolę jednoznacznego identyfikatora rekordu. W praktyce oznacza to, że dla każdej krotki (wiersza) w tabeli wartość klucza głównego musi być unikalna i nie może być pusta (NULL). Systemy baz danych, takie jak MySQL, PostgreSQL, SQL Server czy Oracle, egzekwują te zasady automatycznie – jeśli spróbujesz wstawić drugi rekord z tą samą wartością klucza głównego, dostaniesz błąd naruszenia unikalności. Moim zdaniem to jedna z kluczowych zasad normalnego projektowania baz danych: zawsze projektujemy tabelę zaczynając od przemyślania klucza głównego. W aplikacjach webowych bardzo często używa się prostego klucza głównego typu liczbowego (np. INT AUTO_INCREMENT lub SERIAL), który jest technicznym identyfikatorem rekordu. Dzięki temu łatwo się odwołać do konkretnego użytkownika, zamówienia czy produktu po jego ID. Klucz główny jest też podstawą do definiowania kluczy obcych w innych tabelach – relacje typu 1:N czy N:M opierają się właśnie na odwołaniach do wartości PRIMARY KEY. Z mojego doświadczenia wynika, że stosowanie sztucznych (surrogate) kluczy głównych, zamiast kombinowania z wieloma polami naturalnymi, upraszcza później zapytania SQL, modyfikacje struktury i integrację z kodem w PHP czy JavaScript. W dobrze zaprojektowanej bazie danych każda tabela relacyjna powinna mieć jasno zdefiniowany klucz główny, bo bez tego trudno mówić o porządnym zarządzaniu danymi, spójności referencyjnej i wydajnym indeksowaniu.
W tym zagadnieniu łatwo pomylić różne typy pól i ich role w bazie danych, szczególnie gdy ktoś dopiero zaczyna przygodę z SQL i projektowaniem relacyjnych baz danych. Jednoznaczny identyfikator rekordu to takie pole, które pozwala bez żadnych wątpliwości wskazać dokładnie jeden wiersz w tabeli. W standardzie relacyjnych baz danych tę rolę pełni klucz główny, oznaczany jako PRIMARY KEY. Klucz obcy jest często mylony z kluczem głównym, bo też dotyczy identyfikatorów, ale jego zadanie jest inne. Foreign key służy do tworzenia powiązań między tabelami – przechowuje wartości klucza głównego z innej tabeli. Sam w sobie nie musi być unikalny, wręcz przeciwnie, w relacji 1:N zwykle powtarza się wiele razy. Dlatego nie może być uznany za jednoznaczny identyfikator rekordu w swojej tabeli. Gdybyśmy próbowali identyfikować rekordy po kluczu obcym, szybko okazałoby się, że wiele wierszy ma tę samą wartość i nie da się wskazać jednego, konkretnego. Kolejny typ błędnego rozumowania to przekonanie, że o byciu identyfikatorem decyduje typ danych, np. logiczny albo tekstowy. Typ logiczny (BOOLEAN, TINYINT(1) itp.) ma zwykle tylko dwie możliwe wartości: true/false, 0/1. Nietrudno zauważyć, że w dowolnej realnej tabeli więcej niż dwa rekordy nie będzie mogło mieć unikalnej wartości takiego pola, więc nie da się w ten sposób jednoznacznie identyfikować wierszy. Typ tekstowy też sam w sobie niczego nie gwarantuje. Można mieć kolumnę VARCHAR z e-mailem użytkownika, ale jeśli nie nałożymy ograniczenia unikalności i nie oznaczymy jej jako klucz główny, baza danych nie będzie pilnowała, by wartości się nie powtarzały. Częsty błąd myślowy polega na tym, że skoro w praktyce „zazwyczaj” coś jest unikalne (np. PESEL, e-mail), to ktoś zakłada, że to automatycznie jest klucz główny. Tymczasem dopiero formalne zadeklarowanie PRIMARY KEY (ewentualnie UNIQUE + NOT NULL, ale to już bardziej obejście) nadaje kolumnie rolę jednoznacznego identyfikatora w sensie technicznym. Dlatego nie typ danych, nie to czy pole wygląda na ważne, tylko jego definicja jako klucza głównego w strukturze tabeli decyduje o tym, że identyfikuje rekord jednoznacznie.