Kwalifikacja: MED.07 - Montaż i eksploatacja urządzeń elektronicznych i systemów informatyki medycznej

Wielu osobom początkującym zdarza się mylić pojęcia takie jak UNIQUE, DISTINCT czy NOT NULL z kluczem podstawowym, bo wszystkie jakoś tam ograniczają powtarzanie lub puste wartości, ale ich rola i miejsce w strukturze bazy danych są zupełnie inne. UNIQUE rzeczywiście pilnuje unikalności wartości w danej kolumnie, ale nie zabezpiecza przed NULL-ami i nie nadaje właściwości identyfikatora rekordu. To taki „miękki” ogranicznik, bo możesz mieć kilka UNIQUE w jednej tabeli, a PRIMARY KEY zawsze jest tylko jeden. DISTINCT to raczej słowo kluczowe w zapytaniach SELECT – pozwala wyciągnąć tylko niepowtarzające się wyniki, nie jest żadnym ograniczeniem na poziomie definicji tabeli. Zdarza się, że ktoś próbuje użyć DISTINCT tam, gdzie chodzi o spójność danych strukturalnie, ale to zupełnie inny etap – DISTINCT działa w wynikach, nie w strukturze tabeli. NOT NULL natomiast uniemożliwia wpisanie pustych wartości do kolumny, ale w żaden sposób nie pilnuje unikalności ani nie nadaje statusu klucza – to tylko ochroniarz przed NULL-ami, a nie przed duplikatami. Typowym błędem jest przekonanie, że wystarczy oznaczyć kolumnę jako NOT NULL i już jest wszystko OK, ale to nie załatwia sprawy identyfikatora. W praktyce, kiedy nie stosuje się PRIMARY KEY, rodzi się mnóstwo problemów ze spójnością danych, relacjami i wydajnością zapytań. Tak więc, żadna z tych opcji nie zastępuje klucza podstawowego, bo tylko PRIMARY KEY daje nam pełną gwarancję unikalności i integralności rekordów w tabeli oraz pozwala tworzyć relacje pomiędzy tabelami zgodnie z modelowaniem relacyjnej bazy danych. Moim zdaniem warto naprawdę dobrze zrozumieć, na czym polega różnica między tymi ograniczeniami – to klucz do sensownego projektowania baz danych, szczególnie w większych, rozbudowanych systemach.