Poprawna kwerenda używa składni CREATE TABLE z listą kolumn i ich typów danych: CREATE TABLE samochod (marka CHAR(30), model CHAR(30), cena DECIMAL(15,2));. To dokładnie odpowiada treści zadania. Atrybuty marka i model są typu tekstowego, więc zastosowano CHAR(30) – stałej długości łańcuch znaków. W praktyce w wielu projektach częściej używa się VARCHAR zamiast CHAR (bo oszczędza miejsce przy krótszych napisach), ale użycie CHAR(30) jest jak najbardziej poprawne i zgodne ze składnią SQL. Kluczowy jest tu typ ceny. W zadaniu jest mowa o liczbie rzeczywistej typu stałoprzecinkowego, czyli takiej, która przechowuje część ułamkową, ale w sposób dokładny, a nie przybliżony. Do tego właśnie służy DECIMAL(p,s) (lub NUMERIC), gdzie p to precyzja (łączna liczba cyfr), a s to skala (liczba cyfr po przecinku). DECIMAL(15,2) oznacza liczbę z maksymalnie 15 cyframi, z czego 2 po przecinku, czyli świetnie nadaje się np. do przechowywania cen w złotówkach i groszach: 1234567890123,45 mieści się w takim typie. To jest standardowa, dobra praktyka w systemach finansowych, sklepach internetowych, systemach magazynowych itp., bo unikamy błędów zaokrągleń charakterystycznych dla typów zmiennoprzecinkowych jak FLOAT czy DOUBLE. W realnych bazach danych (MySQL, PostgreSQL, SQL Server) kolumny z cenami, stawkami VAT, rabatami procentowymi prawie zawsze definiuje się właśnie jako DECIMAL z odpowiednią skalą, a nie jako typy binarne zmiennoprzecinkowe. Warto też zauważyć, że prawidłowa składnia CREATE TABLE nie używa słowa VALUES przy definiowaniu struktury tabeli – po nazwie tabeli od razu podajemy listę kolumn z typami, tak jak w wybranej odpowiedzi. Taka konstrukcja jest zgodna z SQL-92 i wspierana przez wszystkie popularne systemy bazodanowe.
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.