Kwalifikacja: INF.03 - Tworzenie i administrowanie stronami i aplikacjami internetowymi oraz bazami danych

W bazach danych bardzo łatwo pomylić różne typy ograniczeń, bo wszystkie „coś ograniczają”, ale robią to w zupełnie inny sposób. W tym pytaniu chodzi konkretnie o to, żeby wartości w kolumnie się nie powtarzały – czyli o klasyczną unikalność danych. Do tego służy constraint UNIQUE, który jest standardowym mechanizmem w SQL do wymuszania niepowtarzalnych wartości w obrębie danej kolumny lub kombinacji kolumn. Pojawia się czasem intuicja, że może istnieje coś takiego jak SINGLE albo NO REPEAT, bo nazwa brzmi sensownie po angielsku. W specyfikacji SQL i w popularnych systemach baz danych takie słowa kluczowe jednak po prostu nie występują jako constrainty. SINGLE i NO REPEAT nie są standardowymi ograniczeniami, więc żadna poważna baza danych ich nie zrozumie. To typowy błąd: kierowanie się „ładnie brzmiącą nazwą”, a nie faktycznymi słowami kluczowymi języka SQL. Z kolei NOT NULL jest jak najbardziej prawdziwym ograniczeniem, ale rozwiązuje zupełnie inny problem. NOT NULL mówi tylko tyle, że w danej kolumnie nie wolno przechowywać wartości pustych (NULL). Możesz mieć tabelę, w której kolumna ma NOT NULL i jednocześnie wiele identycznych wartości, np. same zera albo ten sam tekst w każdym wierszu – baza nie będzie protestować, bo nie zabrania powtórek, tylko zabrania braku wartości. To ograniczenie często łączy się z innymi, np. PRIMARY KEY czy UNIQUE, ale samo w sobie nie zapewnia żadnej unikalności. Z mojego doświadczenia przy projektowaniu schematów baz danych najczęstszy błąd myślowy wygląda tak: ktoś zakłada, że skoro pole nie może być puste (NOT NULL), to „jakoś przy okazji” jest traktowane specjalnie i może nawet unikalnie. Niestety tak to nie działa. Dopiero dodanie UNIQUE albo zdefiniowanie PRIMARY KEY wymusza, że dana wartość nie pojawi się drugi raz. Dlatego przy każdej kolumnie, która ma pełnić rolę identyfikatora biznesowego (np. email, numer dokumentu, NIP), trzeba świadomie dobrać właściwy constraint, a nie liczyć na samo NOT NULL czy jakieś „domyślne” zachowanie bazy.