Poprawna składnia to ALTER TABLE produkt ADD PRIMARY KEY (id), bo dokładnie to polecenie dodaje do istniejącej tabeli nowy klucz podstawowy oparty na kolumnie id. Instrukcja ALTER TABLE służy do modyfikowania struktury tabeli, a klauzula ADD PRIMARY KEY definiuje ograniczenie (constraint) typu klucz podstawowy dla wskazanej kolumny lub zestawu kolumn. W praktyce oznacza to, że kolumna id musi być unikalna i nie może przyjmować wartości NULL. Silnik bazy danych (np. MySQL, PostgreSQL, SQL Server) zwykle tworzy do tego indeks typu UNIQUE, który przyspiesza wyszukiwanie po kluczu głównym. Moim zdaniem warto pamiętać, że takie polecenie będzie działać tylko wtedy, gdy dane w kolumnie id już spełniają warunki klucza podstawowego: brak duplikatów i brak wartości pustych. W realnym projekcie często robi się to w dwóch krokach: najpierw uzupełnia się brakujące wartości, usuwa lub poprawia duplikaty, a dopiero potem dodaje PRIMARY KEY. Przykładowo: ALTER TABLE produkt ADD PRIMARY KEY (id); W wielu systemach, zwłaszcza w aplikacjach webowych, kolumna id jest też często ustawiana jako AUTO_INCREMENT (MySQL) lub używa sekwencji (PostgreSQL, Oracle). Wtedy definicja tabeli przy tworzeniu może wyglądać np. tak: CREATE TABLE produkt (id INT PRIMARY KEY AUTO_INCREMENT, nazwa VARCHAR(100)); Jeśli jednak tabela już istnieje i kolumna id była zwykłą kolumną, to właśnie ALTER TABLE ... ADD PRIMARY KEY (id) jest standardowym, poprawnym sposobem nadania jej roli klucza głównego. To rozwiązanie jest zgodne z ogólną składnią SQL i dobrą praktyką modelowania relacyjnych baz danych, gdzie każda tabela powinna mieć jasno zdefiniowany klucz podstawowy, najlepiej prosty, stabilny i jednoznaczny.
W SQL do modyfikowania struktury tabeli służy instrukcja ALTER TABLE, ale poszczególne warianty tej komendy robią bardzo różne rzeczy. W tym zadaniu chodzi konkretnie o dodanie atrybutu klucza podstawowego do istniejącej kolumny id, więc potrzebne jest utworzenie ograniczenia typu PRIMARY KEY dla tej kolumny. Właśnie to robi składnia z klauzulą ADD PRIMARY KEY (id). Częsty błąd polega na myleniu zmiany typu kolumny albo usuwania ograniczeń z ich dodawaniem. Polecenie ALTER TABLE produkt ALTER COLUMN id INT jedynie zmienia definicję kolumny, na przykład jej typ danych, domyślną wartość, ewentualnie atrybuty typu NOT NULL, w zależności od dialektu SQL. Nie tworzy ono żadnego klucza podstawowego. Ktoś może myśleć, że „ALTER COLUMN” doda jakieś specjalne właściwości, ale samo ustawienie typu INT nie ma nic wspólnego z unikalnością czy identyfikacją wierszy. Z kolei ALTER TABLE produkt DROP CONSTRAINT id sugeruje usunięcie istniejącego ograniczenia o nazwie id. Takiego polecenia używa się wtedy, gdy constraint już istnieje i chcemy go skasować, na przykład przed zmianą klucza głównego. To jest operacja odwrotna do dodawania ograniczenia, więc nie rozwiązuje problemu z treści pytania. Podobnie ALTER TABLE produkt DROP PRIMARY KEY usuwa bieżący klucz podstawowy z tabeli. W niektórych silnikach SQL to polecenie jest wręcz wymagane, zanim zdefiniuje się nowy klucz. W każdym razie DROP PRIMARY KEY nie dodaje żadnego klucza, tylko go likwiduje. Typowym źródłem pomyłek jest myślenie „skoro chcę coś zmienić w kolumnie, to ALTER COLUMN wystarczy” albo „DROP/ADD, jakoś to będzie”. W praktyce trzeba rozróżniać trzy poziomy: definicję samej kolumny (typ, rozmiar, NULL/NOT NULL), definicje ograniczeń (PRIMARY KEY, UNIQUE, FOREIGN KEY) oraz indeksy. Klucz podstawowy jest właśnie constraintem, więc operujemy na nim poprzez ADD PRIMARY KEY, a nie przez samą zmianę typu kolumny czy usuwanie ograniczeń. Dobrą praktyką jest też zawsze sprawdzić, jakie ograniczenia aktualnie istnieją w tabeli, zanim zacznie się je modyfikować.