KREDа AVG() как раз и не будет использоваться ... ибо мерять температуру по больнице нет смысла ...
Хм. Вообще-то средняя величина предоплаты - это не "средняя температура по больнице" и должна считаться безо всяких нулей.

KREDв каких моментах использование НУЛЛ и АВГ/СУМ приводит к логической ошибке ?
SUM поля NULL игнорирует. Поэтому само по себе использование SUM привести к ошибке не может, пока результат выполнения SUM не пытаться интерпретировать не как SUM.
AVG по сути SUM/COUNT, соответственно, беда будет в COUNT. Точнее, в интерпретации того COUNT, который сервер будет использовать в AVG.
Нахождение средней величины предоплаты Вам уже привели в качестве примера.

senleftНапример, в своей БД я могу вполне отказаться от null в поле "сумма предоплаты" и подставить значение по умолчанию "0"
Как раз все наоборот. Ограничение на значение этого поля - NULL или больше нуля.

Ex_Soft(sum(sales)-sum(quota)) != sum(sales-quota)
Вам не кажется, что сложение и вычитание NULL не то же самое, что SUM по полю, которое может принимать значения NULL?

KREDно я не понимаю почему вы предираетесь к моим словам
Я крайне редко придираюсь к словам из-за спортивного интереса. Возможно, я что-то невнятно объяснил. Тогда спросите об этом подробнее и яснее.

[quot KRED]
Мне не понятно ...
Если принимать под значением НУЛЛ отсутствие платежа , то средние будет считатьса отлично (по присутствующим платежам , а не по всем возможным) ...
Но скажу сразу что легче было бы отказаться в этом случае от НУЛЛ и заноссить в колонку "0" .
Что не будет противоречить логике ... я не прав ?
Во-первых, если Вы говорте о неком поле как о предоплате, то это либо плановое значение предоплаты, либо какая-то очень узкая специфика, потому что предоплат (предварительных платежей) фактически может быть много, а нормальный календарь платежей на одном поле не сделать даже в качестве дипломной работы.
Во-вторых, величина предоплаты либо положительна, либо предоплаты нет вообще. Нельзя заплатить 0 денег, это нонсенс. В этом смысле предоплата от обычного платежа ничем не отличается. Если не пытаться привнести логику, которую еще надо обосновать по месту, то вырисовывается совершенно четкий constraint, который я и написал выше. Чтобы использовать другой constraint, необходимо его обосновать. Вы в состоянии обосновать, что default 0 not null + лишняя логика в запросах будут чем-то лучше?

KREDИз каких убеждений вы решили использовать для такого поля значения НУЛЛ ?
Контора может работать как с использованием предоплаты, так и без использования предоплаты. Предоплата в первом случае составляет 30%. Если Вы будете забабахивать нули в преоплату, то в один прекрасный момент обнаружите, что средняя предоплата почему-то стала 10%, а не 30%, и чтобы все вернуть на круги своя, придется править запросы, которые бы исключали договора без предоплаты из расчета средней предоплаты по договорам. Оно Вам надо?

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

KREDСергей Васкецов
Хм. Вообще-то средняя величина предоплаты - это не "средняя температура по больнице" и должна считаться безо всяких нулей.
??????
Я имел в виду, что средняя величина предоплаты (особеннов разных разрезах, например, по менеджерам) может иметь вполне обоснованный интерес и не является сферическим конем в вакууме, в отличие от средней температуры по больнице, не имеющей большого смысла.