Powszechnie przyjmuje się, że klucze podstawowe powinny być niezmienne (lub tak stabilne, jak to możliwe, ponieważ niezmienności nie można wymusić w DB). Chociaż nic nie stoi na przeszkodzie, aby zaktualizować klucz podstawowy (z wyjątkiem ograniczenia integralności), może to nie być dobry pomysł:
Z punktu widzenia wydajności:
- Będziesz musiał zaktualizować wszystkie klucze obce, które odwołują się do zaktualizowanego klucza. Pojedyncza aktualizacja może prowadzić do aktualizacji potencjalnie wielu tabel/wierszy.
- Jeśli klucze obce są nieindeksowane (!!), będziesz musiał utrzymać blokadę w tabeli podrzędnej, aby zapewnić integralność. Oracle utrzyma blokadę tylko przez krótki czas, ale i tak jest to przerażające.
- Jeśli twoje klucze obce są indeksowane (tak jak powinny), aktualizacja doprowadzi do aktualizacji indeksu (usuń+wstaw w strukturę indeksu), jest to zazwyczaj droższe niż rzeczywista aktualizacja tabeli podstawowej.
- W tabelach INDEKS ORGANIZACJI (w innych RDBMS, patrz klastrowany klucz podstawowy) wiersze są fizycznie sortowane według klucza podstawowego. Aktualizacja logiczna spowoduje fizyczne usunięcie + wstawienie (droższe)
Inne uwagi:
- Jeśli do tego klucza odwołuje się jakikolwiek system zewnętrzny (pamięć podręczna aplikacji, inna baza danych, eksport...), odniesienie zostanie przerwane podczas aktualizacji.
- dodatkowo, niektóre RDBMS nie obsługują CASCADE UPDATE, w szczególności Oracle.
Podsumowując, podczas projektowania ogólnie bezpieczniej jest używać klucza zastępczego zamiast naturalnego klucza podstawowego, który powinien się nie zmieniać – ale może ostatecznie wymagać aktualizacji z powodu zmienionych wymagań lub nawet błędu wprowadzania danych.
Jeśli koniecznie musisz zaktualizować klucz podstawowy za pomocą tabeli dzieci, zapoznaj się z tym postem Toma Kyte, aby znaleźć rozwiązanie.
