Jednoznacznym identyfikatorem rekordu w bazie danych jest pole

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.