W bazach danych typ DECIMAL jest przeznaczony do przechowywania

Poprawnie – typ DECIMAL w bazach danych jest przeznaczony do przechowywania liczb rzeczywistych stałoprzecinkowych, czyli takich, gdzie liczba miejsc po przecinku jest z góry określona i zawsze dokładnie reprezentowana. W definicji kolumny podajemy zwykle dwa parametry, np. DECIMAL(10,2), gdzie 10 to całkowita liczba cyfr, a 2 to liczba cyfr po przecinku. Dzięki temu baza wie, że np. wartość 1234,50 będzie przechowywana bez zaokrągleń binarnych, które występują w typach zmiennoprzecinkowych (FLOAT, DOUBLE). To jest kluczowe w zastosowaniach finansowych: kwoty pieniędzy, stawki VAT, kursy walut, limity kredytowe, rozliczenia magazynowe. W takich miejscach nawet jeden grosz różnicy przy dużej liczbie operacji potrafi narobić bałaganu. Moim zdaniem w projektach produkcyjnych dobra praktyka jest taka, że wszystko, co ma sens biznesowy jako „kwota”, „saldo”, „cena jednostkowa”, „rabat procentowy z dokładnością do dwóch lub czterech miejsc” trzymamy właśnie w DECIMAL/NUMERIC, a nie w FLOAT. Standard SQL definiuje typy DECIMAL i NUMERIC jako typy dokładne (exact numeric), co oznacza, że operacje arytmetyczne na nich są przewidywalne i nie generują dziwnych ogonków typu 1.199999999 zamiast 1.2. W wielu silnikach (MySQL, PostgreSQL, SQL Server) DECIMAL jest implementowany wewnętrznie jako zapis dziesiętny, często podobny do „dużej liczby całkowitej” z wirtualnym przecinkiem w określonym miejscu. Dobrą praktyką jest też dobór precyzji z zapasem, np. DECIMAL(18,4) dla kwot w systemach księgowych, żeby uniknąć przepełnień przy większych sumach. W praktyce webowej, gdy aplikacja PHP czy JavaScript komunikuje się z bazą, to właśnie typ DECIMAL pozwala zachować spójność między tym, co widzi użytkownik na formularzu, a tym, co finalnie zapisuje się w tabeli – bez ukrytych błędów zaokrągleń.