9
MSDN mówi o precyzji i scale of decimal multiplicatuion result:T SQL dziesiętny mnożenia
- Dokładność wyników oraz podziałce bezwzględnego maksimum 38. Po precyzyjnym wynik jest większy niż 38, odpowiednia waga zmniejsza się do zapobiec obcięciu części integralnej wyniku.
Więc kiedy wykonujemy to:
DECLARE @a DECIMAL(18,9)
DECLARE @b DECIMAL(19,9)
set @a = 1.123456789
set @b = 1
SELECT @a * @b
wynik jest 1.12345689000000000 (9 zer) i widzimy, że to nie jest obcięty, ponieważ 18 + 19 + 1 = 38 (do limitu).
Kiedy podnosimy dokładność @a do 27, tracimy wszystkie zera, a wynik to zaledwie 1.123456789. Idąc dalej, kontynuujemy obcinanie i uzyskujemy wynik zaokrąglenia. Na przykład zwiększenie precyzji @a do 28 daje 1,12345679 (8 cyfr).
Interesujące jest to, że w pewnym momencie, z precyzją równą 30, mamy 1.123457 i wynik ten nie zmieni się dalej (przestaje być obcięty).
31, 32 i do 38 wyników w tym samym. Jak to wyjaśnić?
Po prostu wpadłem na pomysł: może to zrobić, aby użytkownicy nie utracili swoich dziesiętnych znaków (cyfr po przecinku) całkowicie, gdy użyli funkcji sum(). Zawsze zwraca dziesiętny (38, s) i nie daje żadnego adekwatnego wyniku (w sensie uzyskania wartości niecałkowitej) po pomnożeniu na dowolnym dziesiętnym z tym samym niezerowym s (lub nawet s-1, gdy s> = 2). Ale 6 cyfr, które są "zarezerwowane" dla tego przypadku, nadal wydaje się dość zaskakujące. Może trochę dokumentacji na ten temat? – Ilya