SUM (Column_Value) дает значение, отличное от значения калькулятора
Ниже приведены значения столбцов в моей таблице sql. Когда я складываю их с помощью настольного калькулятора, я получаю сумму как 0
Но в sql, когда я беру сумму Item_Quantity, я получаю странное значение, как показано ниже
Тип данных этого столбца - float. Могу я получить помощь по этому поводу? Спасибо.
Если вы хотите работать с точные десятичные данные, значит, вы выбрали неправильный тип данных для его представления. То, что вы показываете, не является неожиданным результатом из-за того, что float не может точно представлять все значения десятичный.
Возможный дубликат Математика с плавающей запятой не работает?
Если вы не знакомы с синтаксисом, обратите внимание, что «-3.55E-15» означает «-3,55 * 10 ^ -15», то есть -0,00000000000000355.
Обычно вы можете изменить тип столбца на десятичный, если вам нужны точные результаты. Но имейте в виду, что десятичные вычисления обычно медленнее, чем с плавающей запятой. Предлагаю прочитать: stackoverflow.com/questions/1056323/…
@Nisarg, не могли бы вы перевести сумму в десятичное число, чтобы получить скорость операции FP, но точность десятичной дроби? Например, SELECT CAST(-0.00000000000000355 AS decimal) возвращает 0. Я думаю, что это не совсем точность - больше похоже на округление.
@Nisarg Я изменил тип данных на десятичный (18,0), но он все еще не дает мне 0, вместо этого он дает мне -2
decimal(18,0) не будет работать, так как ваши данные состоят из десятичных знаков, попробуйте decimal(18,1)Числа с плавающей запятой внутри представляются как двоичные числа. Например. 0.2 - это двоичный 0.00110011001100110011... с бесконечным количеством повторений 0011, которые, конечно, должны быть усечены в компьютере. Поэтому вы видите небольшую ошибку. См .: Конвертер десятичных чисел в двоичные
Лично с этими конкретными данными я бы использовал decimal(3,1), нет необходимости иметь шкалу выше 3, учитывая, что самые высокие / самые низкие значения - это 12.8 и -16.6 соответственно.
@Mazhar спасибо, но ваше решение не сработало, я все еще получаю значение -2.0
@sumedha Вы должны использовать decimal(19, 4) - то есть точность до 19 цифр, где 4 из этих цифр идут после десятичной точки. Если вы работаете с меньшими числами, вы можете использовать decimal(10, 4).
Если вы все еще не можете получить ожидаемый результат, я бы предложил создать минимальный воспроизводимый пример. Возможно, вы сможете использовать sqlfiddle.com для создания рабочего примера.
Если вы изменили тип столбца на 18,0, возможно, вы удалили десятичные дроби, теперь все ваши данные повреждены.
Рабочий пример с DECIMAL(18,1): sqlfiddle.com/#!18/603c9/2
@DavidFaber: это округление является - без дополнительной спецификации DECIMAL означает DECIMAL(18, 0), то есть вы просто округляете до числа без цифр после десятичной точки. Естественно, это приведет вас к 0, но это не тот тип данных, который вы хотите использовать для хранения. (И не указывать точность и масштаб - плохая идея, потому что правила определения точности и масштаба при объединении разных значений довольно загадочны - явное указание помогает предотвратить сюрпризы.)
См .: sqlfiddle.com/#!18/bc23c/1/0
@IMSoP, Спасибо, восстановил базу данных и еще раз проверил, все работает! спасибо за пример
Ответы 1
Не уверен, почему вы говорите, что использование DECIMAL(18,1) не будет работать
Вот ваши образцы данных
DECLARE @t TABLE ( Item_Quanity FLOAT)
INSERT INTO @t
(
Item_Quanity
)
VALUES
(12.8) ,(-6.8) ,(1.4) ,(0.2) ,(3.4) ,(-2.8), (12) ,(-3.6) ,(-16.6)
Вот ваш запрос
SELECT SUM(Item_Quanity) FROM @t
что дает этот результат
(No column name)
-3.5527136788005E-15
Вот модификация этого запроса с использованием CAST
SELECT SUM(CAST(Item_Quanity AS DECIMAL(18,1))) FROM @t
Что дает такой результат
(No column name)
0.0
Теперь меняем тип данных с FLOAT на `DECIMAL (18,1)
DECLARE @t1 TABLE ( Item_Quanity DECIMAL(18,1))
INSERT INTO @t1
(
Item_Quanity
)
VALUES
(12.8) ,(-6.8) ,(1.4) ,(0.2) ,(3.4) ,(-2.8), (12) ,(-3.6) ,(-16.6)
SELECT SUM(Item_Quanity)
FROM @t1
Что возвращается
(No column name)
0.0
Спасибо, это сработало. Я снова восстановил базу данных и проверил, теперь она работает.
Это значение с плавающей запятой, близкое к 0.