9 мая 2011 г. 21:10 пользователь Artem Chuprina <r...@ran.pp.ru> написал:
> Думаю, это не принципиально, можно придумать ситуацию, когда запись таки > > должна появиться. Например, если подобное поле в таблице не одно, а их > > больше, и в другом поле за сегодня существует некое число. > > Можно придумать ситуацию, когда такая _оптимизация_ оправдана. А ситуацию, > когда запись таки _должна_ появиться, придумать нельзя. > Хорошо - есть таблица людей, где есть поле "серия паспорта", но некоторые из людей еще не имеют его по возрасту. Надо для каждого атрибута заводить отдельную таблицу пересечений - из-за того, что атрибут у кого-то может просто _отсутствовать_? > Потому что ... представь себе ситуацию, когда тебе нужно посчитать среднюю > минимальную температуру за месяц. Если у тебя в месяце было три дня, когда > никто в отделении не лежал. Задача поставлена корректно, имеет вполне > понятное решение. Нет, для таблицы температура вычисляется не средняя "за месяц", а средняя на дискретном множестве записей. Как будем лечить, если у тебя есть поле типа float с > возможным null? Будем писать "and minTerm is not null"? А если нужно в > том > же запросе выдать еще и агрегат по другому полю, которое в эти дни было не > null? Писать самопальный average? Хотя штатный average наверняка null'ы > игнорирует, как и нужно для этой задачи... > Полагаю, что не только average игнорирует, а вообще любая функция в SQL, равно как и все условия после WHERE. IS NULL означает отсутствие данных атрибута в этой записи, что автоматически выкидывает ее из отбора по любому условию для этого атрибута - если явно не указано условие IS NULL. > > Спор, если я правильно понял, шел о том, можно ли значений типа NULL (или > > undef) вообще избежать, не только в БД. В таком случае мне неясно, что > > должна возвращать функция min() для пустого множества. > > Функция min для пустого множества должна возвращать ошибку тем или иным > способом. > Да, тут принимаю. Тимур.
