Typ DECIMAL w SQL to klasyczny przykład tzw. typu zmiennoprzecinkowego, który w praktyce pozwala na ścisłe określenie, ile cyfr ma być przed i po przecinku. To bardzo praktyczne, szczególnie w aplikacjach finansowych czy wszelkich rozliczeniach, gdzie precyzja liczb jest kluczowa. Nigdy nie wiadomo, ile miejsc po przecinku będzie potrzebne w danym przypadku, dlatego podanie tych parametrów już na etapie projektowania bazy danych jest według mnie super ważne. Moim zdaniem to jedna z tych rzeczy, które odróżniają profesjonalny projekt od takiego pisanego na kolanie. Standardy SQL (jak ANSI SQL) jasno określają, że DECIMAL pozwala na przechowywanie liczb dziesiętnych o dokładnie ustalonej liczbie miejsc przed i po przecinku, co różni go mocno od float czy real, które tego nie gwarantują. W praktyce korzystałem z DECIMAL np. w tabeli przechowującej ceny produktów – gdyby tam był float, mogłyby pojawić się drobne różnice, przez które coś by się nie zgadzało na fakturze. To właśnie DECIMAL daje gwarancję, że 0.1 + 0.2 zawsze będzie równe 0.3, w przeciwieństwie do typów zmiennoprzecinkowych binarnych. Warto o tym pamiętać, bo nawet drobny błąd w typie danych potrafi później wygenerować niemałe kłopoty w systemach rozliczeniowych czy bankowych.
Wybór niewłaściwej odpowiedzi na temat typu DECIMAL często wynika z mylenia podstawowych pojęć związanych z przechowywaniem liczb w bazach danych. Typ stałoprzecinkowy (fixed-point) to określenie, które teoretycznie brzmi podobnie, ale w SQL-u DECIMAL reprezentuje właśnie precyzyjne liczby dziesiętne określone przez użytkownika, a nie dowolny typ stałoprzecinkowy. Co ciekawe, niektórzy mylą DECIMAL z float czy real, które faktycznie są klasycznymi typami zmiennoprzecinkowymi, ale w sensie binarnym i nie dają takiej kontroli nad ilością cyfr po przecinku. To prowadzi do problemów z zaokrągleniami i błędami przy pracy z dużymi liczbami lub liczbami finansowymi. Z kolei typ logiczny (BOOLEAN) to zupełnie inna historia, bo tam przechowuje się jedynie wartości prawda/fałsz, więc w ogóle nie ma mowy o cyfrze przed czy po przecinku. No i typ łańcuchowy (VARCHAR, TEXT) – one przechowują tekst, więc żadnej kontroli nad liczbami i ich postacią nie ma; to byłby spory błąd projektowy użyć go do przechowywania wartości liczbowych z przecinkiem ze względu na ryzyko błędnych danych, niezgodności typów i brak możliwości wykonywania działań matematycznych. Z mojego doświadczenia wynika, że często początkujący programiści kierują się intuicją zamiast zasadami – warto jednak trzymać się standardów SQL, bo one są efektem wielu lat praktyki i analiz. Ostatecznie DECIMAL to najlepszy wybór, gdy zależy nam na dokładnym określeniu liczby miejsc przed i po przecinku, zgodnie z potrzebami biznesowymi i dobrymi praktykami.