Pytanie 1
Której kwerendy SQL należy użyć, aby utworzyć tabelę samochod z atrybutami marka, model, cena, gdzie marka i model są typu tekstowego, natomiast cena jest liczbą rzeczywistą typu stałoprzecinkowego?
A. CREATE TABLE samochod VALUES (marka CHAR(30), model CHAR(30), cena DOUBLE);
B. CREATE TABLE samochod (marka CHAR(30), model CHAR(30), cena DECIMAL(15,2));
C. CREATE TABLE samochod VALUES (marka CHAR(30), model CHAR(30), cena FLOAT);
D. CREATE TABLE samochod (marka INT(30), model INT(30), cena DECIMAL(2,15));
W niepoprawnych propozycjach odpowiedzi widać kilka typowych nieporozumień związanych z SQL-em i typami danych. Po pierwsze, składnia CREATE TABLE nie używa słowa VALUES do definiowania struktury tabeli. VALUES pojawia się przy wstawianiu danych (INSERT INTO ... VALUES ...), a nie przy tworzeniu tabeli. Jeśli po nazwie tabeli pojawia się VALUES, to jest to od razu czerwone światełko, że ktoś pomieszał tworzenie struktury z wstawianiem rekordów. Z mojego doświadczenia to bardzo częsty błąd u osób, które dopiero zaczynają i próbują intuicyjnie łączyć znane słowa kluczowe.
Druga sprawa to dobór typów danych. W zadaniu wyraźnie jest mowa o atrybutach tekstowych dla marka i model. Zastosowanie INT(30) oznacza typ liczbowy całkowity, a nie tekstowy. Nawet jeśli ktoś myśli, że w nawiasie wpisuje się „ilość znaków”, to w przypadku INT(30) tak to nie działa – ten nawias w MySQL ma inne znaczenie (szerokość wyświetlania), a w nowoczesnych wersjach i tak jest ignorowany. Marka samochodu typu „Audi” czy „Toyota” po prostu nie zmieści się w typie liczbowym, bo to nie jest reprezentacja tekstowa.
Trzeci istotny błąd dotyczy kolumny cena. Zadanie wymaga liczby rzeczywistej typu stałoprzecinkowego. Typy FLOAT czy DOUBLE są typami zmiennoprzecinkowymi binarnymi, które przechowują przybliżone wartości i mogą wprowadzać drobne błędy zaokrągleń. To jest nieakceptowalne przy pieniądzach, bo kwoty muszą się dokładnie zgadzać co do grosza. Dlatego stosuje się DECIMAL lub NUMERIC, gdzie jawnie podajemy precyzję i skalę, np. DECIMAL(15,2). Odwrócenie tych wartości, jak w DECIMAL(2,15), jest bez sensu w kontekście cen – oznaczałoby maksymalnie dwie cyfry łącznie i piętnaście po przecinku, co w praktyce nie ma zastosowania. Takie konstrukcje biorą się zwykle z mechanicznego wpisywania liczb bez zrozumienia, co oznacza precyzja i skala. Dobra praktyka w branży jest taka, że dla kwot pieniężnych używa się DECIMAL z 2 miejscami po przecinku, ewentualnie 3–4 w specyficznych zastosowaniach, a tekst przechowuje się w typach znakowych, nie liczbowych. Rozumienie tych zasad bardzo ułatwia późniejsze projektowanie sensownych schematów baz danych.
Druga sprawa to dobór typów danych. W zadaniu wyraźnie jest mowa o atrybutach tekstowych dla marka i model. Zastosowanie INT(30) oznacza typ liczbowy całkowity, a nie tekstowy. Nawet jeśli ktoś myśli, że w nawiasie wpisuje się „ilość znaków”, to w przypadku INT(30) tak to nie działa – ten nawias w MySQL ma inne znaczenie (szerokość wyświetlania), a w nowoczesnych wersjach i tak jest ignorowany. Marka samochodu typu „Audi” czy „Toyota” po prostu nie zmieści się w typie liczbowym, bo to nie jest reprezentacja tekstowa.
Trzeci istotny błąd dotyczy kolumny cena. Zadanie wymaga liczby rzeczywistej typu stałoprzecinkowego. Typy FLOAT czy DOUBLE są typami zmiennoprzecinkowymi binarnymi, które przechowują przybliżone wartości i mogą wprowadzać drobne błędy zaokrągleń. To jest nieakceptowalne przy pieniądzach, bo kwoty muszą się dokładnie zgadzać co do grosza. Dlatego stosuje się DECIMAL lub NUMERIC, gdzie jawnie podajemy precyzję i skalę, np. DECIMAL(15,2). Odwrócenie tych wartości, jak w DECIMAL(2,15), jest bez sensu w kontekście cen – oznaczałoby maksymalnie dwie cyfry łącznie i piętnaście po przecinku, co w praktyce nie ma zastosowania. Takie konstrukcje biorą się zwykle z mechanicznego wpisywania liczb bez zrozumienia, co oznacza precyzja i skala. Dobra praktyka w branży jest taka, że dla kwot pieniężnych używa się DECIMAL z 2 miejscami po przecinku, ewentualnie 3–4 w specyficznych zastosowaniach, a tekst przechowuje się w typach znakowych, nie liczbowych. Rozumienie tych zasad bardzo ułatwia późniejsze projektowanie sensownych schematów baz danych.
