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

W tym zadaniu bardzo łatwo wpaść w pułapkę skojarzeń z programowaniem w innych językach, gdzie nawias przy typie sugeruje rozmiar tablicy albo liczbę elementów. W SQL, a szczególnie w składni zbliżonej do MySQL, zapis `INTEGER(3)` nie tworzy trzech kolumn ani trzyelementowej tablicy, tylko opisuje jedną kolumnę typu liczbowego. Nawias w tym miejscu oznacza co najwyżej szerokość wyświetlania albo pewne ograniczenie prezentacji, a nie ilość powtórzeń typu. Dlatego interpretacja, że tabela ma trzy kolumny typu całkowitego, jest po prostu przeniesieniem logiki z np. C lub Java na SQL, co jest częstym, ale błędnym nawykiem. Podobnie mylenie `INTEGER(3)` z tablicą trzyelementową wynika z tego, że w wielu językach zapis z nawiasami kwadratowymi czy okrągłymi kojarzy się z kolekcją. W relacyjnych bazach danych pojedyncza kolumna przechowuje pojedynczą wartość skalarnej dziedziny (liczba, tekst, data), a nie tablicę, chyba że używamy bardzo specyficznych typów, jak np. ARRAY w PostgreSQL – ale to wygląda zupełnie inaczej w definicji. Kolejny błąd to założenie, że skoro przy typie pojawia się liczba 3, to kolumny zostaną automatycznie nazwane `kolumna1`, `kolumna2`, `kolumna3`. Silniki SQL niczego takiego nie robią. Nazwy kolumn muszą być jawnie podane w definicji tabeli, oddzielone przecinkami, np. `kolumna1 INTEGER, kolumna2 INTEGER, kolumna3 INTEGER`. Jeżeli w nawiasie przy CREATE TABLE jest tylko jeden wpis `kolumna INTEGER(3)`, to mamy dokładnie jedną kolumnę o nazwie `kolumna`. Moim zdaniem dobrym nawykiem jest zawsze patrzeć na przecinki: ile jest elementów oddzielonych przecinkami w nawiasie po nazwie tabeli, tyle jest kolumn. Liczby w nawiasach przy typach (np. VARCHAR(50), DECIMAL(10,2), INT(3)) opisują parametry typu, a nie liczbę kolumn. To podstawowa, ale bardzo ważna zasada przy projektowaniu schematów baz danych i unikaniu dziwnych, mylących interpretacji.