Poprawnie – typ DECIMAL w SQL to typ stałoprzecinkowy. Oznacza to, że już przy definicji kolumny musisz podać dwie wartości: całkowitą liczbę cyfr (PRECISION) oraz liczbę cyfr po przecinku (SCALE), np. DECIMAL(10,2). W praktyce oznacza to, że możesz przechowywać liczby z maksymalnie 10 cyframi, z czego 2 są po przecinku, czyli zakres jest kontrolowany i przewidywalny. Moim zdaniem to jest kluczowa cecha: stała dokładność i brak „pływania” wyniku. W relacyjnych bazach danych DECIMAL jest używany wszędzie tam, gdzie pieniądze, kursy walut, stawki VAT, ilości w magazynie itp. – wszędzie, gdzie liczy się precyzja i nie można sobie pozwolić na błędy zaokrągleń typowe dla typów zmiennoprzecinkowych (FLOAT, DOUBLE). Standard SQL właśnie dla takich zastosowań przewiduje typy numeryczne dokładne (exact numeric types), do których należy DECIMAL/NUMERIC. Dobre praktyki branżowe mówią wprost: kwoty finansowe trzymaj w DECIMAL, a nie w FLOAT. Warto też wiedzieć, że DECIMAL jest przechowywany w sposób „cyfrowy”, a nie binarny jak float, więc operacje arytmetyczne dają wyniki dokładne w zadanej skali. To bardzo ułatwia raportowanie, księgowość, rozliczenia między systemami. W wielu firmach spotkasz standardy projektowe w stylu: „wszystkie kwoty w systemie mają typ DECIMAL(18,2)” albo podobny. Taki zapis daje spójność danych, przewidywalne zużycie miejsca w bazie i mniejsze ryzyko błędów biznesowych. W skrócie: DECIMAL = stałoprzecinkowy, z góry określona liczba cyfr i powtarzalne wyniki obliczeń, co w systemach produkcyjnych jest bardzo ważne.
Typ DECIMAL w SQL bywa mylony z różnymi innymi kategoriami typów, głównie dlatego, że ludzie kojarzą „przecinek” z liczbami zmiennoprzecinkowymi albo traktują wszystko, co ma cyfry, jako coś podobnego do tekstu. W rzeczywistości DECIMAL jest typem stałoprzecinkowym, czyli takim, w którym precyzja i liczba miejsc po przecinku są z góry ustalone przy definicji kolumny. To jest zupełnie inne podejście niż w typach zmiennoprzecinkowych, takich jak FLOAT czy DOUBLE. Tam liczby są przechowywane w formacie binarnym zgodnym mniej więcej ze standardem IEEE 754, a przecinek „pływa”, co prowadzi do drobnych, ale istotnych błędów zaokrągleń. Jeśli ktoś zaznacza odpowiedź zmiennoprzecinkowy, to zwykle wynika z intuicji: skoro jest przecinek, to pewnie float. To jest typowy błąd myślowy. W SQL typy zmiennoprzecinkowe są właśnie po to, by obsługiwać bardzo duże lub bardzo małe wartości kosztem dokładności, np. w obliczeniach naukowych. DECIMAL natomiast ma służyć do obliczeń finansowych i biznesowych, gdzie dokładność jest ważniejsza niż zakres. Z mojego doświadczenia to jedno z częstszych źródeł błędów w młodych projektach: użycie FLOAT do kwot pieniędzy. Odpowiedź logicznym też bywa wybierana trochę „na czuja”, bo ktoś kojarzy, że SQL ma typy TRUE/FALSE, ale DECIMAL nie ma nic wspólnego z logiką boolowską. Typy logiczne przechowują wartości dwustanowe (czasem z NULL jako stanem trzecim), a nie liczby z miejscami po przecinku. Podobnie odpowiedź łańcuchowym wynika z przekonania, że skoro można cyfry zapisać w tekście, to wszystko jedno, czy to tekst, czy liczba. W praktyce typy łańcuchowe (CHAR, VARCHAR, TEXT) nie zapewniają poprawnej arytmetyki, sortowania numerycznego ani kontroli zakresu liczb. Trzymanie wartości liczbowych jako tekst to bardzo zła praktyka: utrudnia indeksowanie, psuje wydajność i powoduje dziwne błędy przy porównaniach (np. '100' < '20' w porządku leksykograficznym). Dobre wzorce projektowania baz danych mówią jasno: liczby trzymaj w typach liczbowych, a wartości wymagające dokładności dziesiętnej w typie stałoprzecinkowym DECIMAL/NUMERIC, z jasno określoną precyzją i skalą.