Вот задумался есть ли разница в запросе:
|    ЕСТЬNULL(СУММА(Продажи.КоличествоОборот),0) КАК ПродажиКоличество
или так:
|    СУММА(ЕСТЬNULL(Продажи.КоличествоОборот,0)) КАК ПродажиКоличество

Есть

лучше второй вариант

(2) +1

2-й по феншую

Есть

Если в Продажи.КоличествоОборот будет NULL, то первое выдаст фигню, а второе будет работать корректно :-)

Спасибо.

На наборе
1
2
NULL
3

Первый выдаст 6, второй 0

(7)Наоборот

Спасибо, все понятно.

(0) первый всегда выдаст число, второй может выдать NULL
(7) оба выдадут 6

(5) ложь это и провокация

(9) тебе врут, а ты веришь

вот уже вторую тему с таким мнением читаю - что второй вариант лучше.

а по моему на агрегатных функциях суммирование как в 7 всегда выдаст нормальное количество

а вот если будет вариант
sum(null), то результат будет null

и первый вариант выдал бы число

т.е. мое мнение - первый корректен, второй - ошибочен

работа их будет с точки зрения юзера - одинаковая, с точки зрения системы лучше 2-й вариант

(13) единственный вариант расхождения в результатах, это вариант пустой выборки

(16) да, я и имею его в виду

>>а вот если будет вариант
sum(null), то результат будет null

второй вариант исключает эту ситуацию, а первый наоборот позволяет

(15) разница есть, но редко встречается

(13) А второй, типа, дату вернет, да?

(16) т.е. когда к, примеру, продаж не было вообще
первый вариант даст 0
второй - null (а как правило, это не то, что нужно)

(2) там не всегда число может получиться, а в 1-м варианте всегда

(21) наоборот. второй даст 0

(20) нет, NULL

(20) второй выдаст null
и при попытке оперирования этим null мы получим ошибку преобразования типов

(23) брешишь

давайте голосовалку

Не думал я, что такой вопрос может мнения раздвоиться.

вы про пустую выборку щас? если она не пустая - 2й вариант даст число всегда. Приведите пример обратного

(27) Как это сделать?

(28) Ну дык лучше часами спорить чем просто проверить.

(29) если выборка непустая, то вариант 1 и 2 эквавалентны полностью
зато если она пустая, то вариант 2 даст ошибку

(30) Критерий истины - практика

Запускаешь 1С, делаешь ТабличнуюЧасть и смотришь сам в запросе...

проверяю:

ВЫБРАТЬ
   ЕСТЬNULL(СУММА(1), 0) КАК Поле1,
   СУММА(ЕСТЬNULL(1, 0)) КАК Поле2
ИЗ
   Справочник.Номенклатура КАК Номенклатура
ГДЕ
   ЛОЖЬ

на непустых выборках результат ВСЕГДА равен

Млин... курите сударь "агрегатные функции" SQL и что выдают они если среди элементов суммирования встречается именно NULL

Для этого и ввели ЕСТЬNULL()

(36) она ихигнорирует просто, не знал?

(36) И что они выдадут?

(35) ё-ё-ё-ё.. ну всё понятно.. про группировки ещё видно не дочитал... Где в твоём запросе группировка??? :-)

Все я проверять полез. На форум и зашел чтобы без тестирования это узнать.

(40) правильно, миста лучший отладчик

(40) зря... тут быдлокодеров тьма тьмущая :-)

(39) она не обязательна вообще то

вообще 1С-ники переняли довольно неудачный вариант, по фэн-шую правильно COALESCE

разница будет на наборах без данных. Первый выдаст 0, второй NULL

Вот запрос накидал:

ВЫБРАТЬ
   спрНом.Ссылка,
   СУММА(ТоварыНаСкладахОстатки.КоличествоОстаток)+1 КАК КоличествоОстаток,
   ЕСТЬNULL(СУММА(ТоварыНаСкладахОстатки.КоличествоОстаток), 0)+1 КАК КоличествоОстаток1,
   СУММА(ЕСТЬNULL(ТоварыНаСкладахОстатки.КоличествоОстаток, 0))+1 КАК КоличествоОстаток2
ИЗ
   Справочник.Номенклатура КАК спрНом
       ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыНаСкладах.Остатки КАК ТоварыНаСкладахОстатки
       ПО спрНом.Ссылка = ТоварыНаСкладахОстатки.Номенклатура
ГДЕ
   спрНом.Ссылка В ИЕРАРХИИ(&Ссылка)

СГРУППИРОВАТЬ ПО
   спрНом.Ссылка
ИТОГИ
   СУММА(КоличествоОстаток),
   СУММА(КоличествоОстаток1),
   СУММА(КоличествоОстаток2)
ПО
   ОБЩИЕ

Сумма итогов:
КоличествоОстаток 2 943,
КоличествоОстаток1 3 123,
КоличествоОстаток2 3 123

Разницы по 1 и второму варианту не вижу, без ЕСТЬNULL отрабатывает некорректно.

Читаем букварь

Агрегатная функция СУММА

Функция вычисляет арифметическую сумму всех попавших в выборку значений поля.

В качестве параметра функции можно указывать только поля, содержащие числовое значение.

Если поле не может содержать числовых значений, то применение функции СУММА к такому полю вызовет ошибку. Если поле может содержать числовые значения (имеет составной тип данных), то данная функция может быть применена к такому полю. Но если среди значений поля в выборке встретится нечисловое значение (помимо значений NULL), это вызовет ошибку.

Много раз перечитываем последнее предложение и думаем, думаем, думаем

(47) я уже давно правильный ответ тут написал и не раз

(46) Тебе 5 раз сказали где разница

(47) У меня только числовое и NULL, поэтому ошибки не вылетает.

(47) здесь не написано, что если среди данных встретиться null, то агрегатная функция вернет ошибку или null

практика, что характерно, подтверждает мое мнение :)

(48) (49) Это хорошо что у вас мнение по этому поводу железное. А как быть мне, если мнения на форуме разошлись?
Спрошу по другому. У меня запрос будет типа (46), какой вариант там выбрать лучше.

(52) в твоем случае без разницы

(53) Спасибо :)

(47) 1 + 2 + 3 + 4 = 10
    1 + 2 + null + 4 = null
    ЕСТЬNULL(1, 0) + ЕСТЬNULL(2,0) + ЕСТЬNULL(null,0) + ЕСТЬNULL(4, 0) = 7

Не видишь разницы?

(55) а теперь с агрегатными функциями ))

(55) В моем случае будет так я понял:

ЕСТЬNULL(1, 0) + ЕСТЬNULL(2,0) + ЕСТЬNULL(null,0) + ЕСТЬNULL(4, 0) = 7
ЕСТЬNULL(1 + 2 + null + 4),0) = 7

Только так: СУММА(ЕСТЬNULL(Продажи.КоличествоОборот,0)).

(57) да. но не 1 + 2 + null + 4
а
СУММА(1, 2, null, 4)

налл + число будет налл
но для агрегатных функций это неверно, они суммируют, игнорируя наллы

(59) Понял

(58)
тогда попробуй на таком запросе
выбрать СУММА(ЕСТЬNULL(Продажи.КоличествоОборот,0))
 из таблицы
 где 1 <> 1

(52) в твоем случае сумма вообще не нужна, как и сгруппировать

(62) Это упрощенный запрос, у меня данные берутся из вложенного запроса, но суть та же.

(55) по-видимому тебе нужно перечитать (47) до просветления.

В приведённом в (0) сабже первый вариант более корректен. Так как агрегат СУММА() при обработке NULL считает его как 0 и нормально суммирует. А вот, если исходный набор будет пустым - агрегат вернёт NULL (в одной единственной строке) - а если написать ЕСТЬNULL(Сумма(Продажи.КоличествоОборот),0) - то в этой строке будет 0.

(65) почему-то уже во второй теме эта простая вещь очень долго до народа доходит :)

кстати, ИМХО, первый вариант чуть лучше еще и тем, что ЕСТЬNULL будет вызываться только один раз после суммирования. Правда, это экономия на спичках, но все же душу греет :)

проголосовала :)

Пусть голосовалка будет :)
Я бы сразу поверил  Как страшно жить, если бы в этой теме не отписался Волшебник, а я на его учебнике учился можно сказать!

Кстати да

появилась голосовалака  значит

Обычно в голосовалках бывает не менее 3-х вариантов и обычно бывает вариант "Прочее" - где тут такое?
Вот, можно было бы и такой вариант предложить
ЕСТЬNULL(СУММА(ЕСТЬNULL(Продажи.КоличествоОборот,0)),0) КАК ПродажиКоличество
Это уж точно наверняка ;)

(71) Уже не могу поменять.

(66)Волшебник за второй вариант - он знает в этом толк ;)

но вот такое:
ЕСТЬNULL(СУММА(Продажи.Количество1 + Продажи.Количество2),0)

работать будет некорректно
думаю, почему - очевидно

(74)В общем случае - да - может работать некорректно
А давайте новую тему и новый опрос откроем
Что лучше

СУММА(ЕСТЬNULL(Продажи.Количество1,0) + ЕСТЬNULL(Продажи.Количество2,0))

или

ЕСТЬNULL(СУММА(Продажи.Количество1) + СУММА(Продажи.Количество2),0)

Кстати, почему-то никто не поднял вопрос, кто такие эти "Продажи" и откуда там вообще могут взяться значения NULL
Например, все таблицы регистра накопления не порождают сами по себе значения NULL - они могут возникнуть только в левых/правых/полных соединениях, с использованием данной таблицы.
В этом случае в(72) поля Количество1 и Количество2 могут быть NULL только одновременно (и это отработает корректно), но если там "Продажи" - это произвольная таблица, скажем из под-запроса - то эти поля в общем случае могут иметь произвольные значения.

(75) тот же принцип, что и в (0)
лучше
ЕСТЬNULL(СУММА(Продажи.Количество1) + СУММА(Продажи.Количество2),0)

потому что агрегатная функция налл в результате дать не может
а 0 + 0 - будет число.

зато в первом варианте опять таки проблемы с пустым множеством
:)

(75)
Упрощенный запрос я привел в (46)

А чтобы тогда не обсудить разницу СУММА(поле1 + поле2) и СУММА(поле1) + СУММА(поле2)?

(78) баян

(76)Кстати, по-моему может, т.к.
1. Когда выборка пустая - будет NULL
2. Когда выборка не пустая, но все значения в суммируемом поле  есть NULL - то в результате тоже будет NULL
Кажется так.
(78)Ну мы тут обработку NULL обсуждали

(80) хм. возможно вы и правы :)
но тогда оба варианта неверны :) и надо тот самый "100% надежный" - обернуть ЕСТЬNULL обе части и еще и снаружи

насколько мне помнится результаты
sum(Isnull()) и Isnull(sum()) могут быть разными в разных субд

(82) Вот нам в этой теме только этого и нехватало ))))))

(83) а, тут уже стеб.. я думал еще по теме...

(84) Нет тут стеба.
Просто уже более менее пришли к выводу. А если эту рассматривать с учетом разных СУБД, то спор будет вечным.

(82) ну, в оракле и скуле вроде бы одинаково, насколько помню

по моему, такое поведение агрегатных функций - стандарт
но за PostgreSQL и DB2 не скажу, конечно...

(86) стандарт - я имею в виду ANSI

(86) не помню, могу наврать, но кажется оракуль ругался на нул в агрегате, но это кажется 8й был
для постгри - прямым не проверял, а из 1с - съедается нормально

(87) а оракуль разве на анси стандарте?

(88) не, насчет оракла точно - 5 лет на нем программила именно на такой конструции как 1 из (0)

(89) ну, часть какую-то соблюдают :)

(90) а я его уже лет 8-9 не видел ))

(89) 9i поддерживал 99-й стандарт
с небольшими отклонениями
точнее даже - с расширениями, я бы сказала

(91) да я тоже уже давно с ним не работаю. Года 3 примерно.

(81)Почему тогда оба не верны? - первый вариант в любом случае отработает корректно (для данного агрегата); а я не припомню ни одной БД, где агрегаты ругались на NULL в соурсных данных. Если только свои собственные агрегатные функции писать (но 1С это не умеет).