9 мая 2011 г. 21:10 пользователь Artem Chuprina
<ran@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 для пустого множества должна возвращать ошибку тем или иным
способом.