> > А эта ситуация, как правило, означает, что база спроектирована > > неправильно. В правильно спроектированной базе будет пара полей "дата - > > минимальная температура", и если сегодня в отделении никто не лежит, то > > записи за сегодня в ней просто не будет. > > > > Думаю, это не принципиально, можно придумать ситуацию, когда запись таки > должна появиться. Например, если подобное поле в таблице не одно, а их > больше, и в другом поле за сегодня существует некое число.
Можно придумать ситуацию, когда такая _оптимизация_ оправдана. А ситуацию, когда запись таки _должна_ появиться, придумать нельзя. Потому что ... представь себе ситуацию, когда тебе нужно посчитать среднюю минимальную температуру за месяц. Если у тебя в месяце было три дня, когда никто в отделении не лежал. Задача поставлена корректно, имеет вполне понятное решение. Как будем лечить, если у тебя есть поле типа float с возможным null? Будем писать "and minTerm is not null"? А если нужно в том же запросе выдать еще и агрегат по другому полю, которое в эти дни было не null? Писать самопальный average? Хотя штатный average наверняка null'ы игнорирует, как и нужно для этой задачи... > Спор, если я правильно понял, шел о том, можно ли значений типа NULL (или > undef) вообще избежать, не только в БД. В таком случае мне неясно, что > должна возвращать функция min() для пустого множества. Функция min для пустого множества должна возвращать ошибку тем или иным способом. -- Программы на Haskell настолько ленивы, что по умолчанию вообще не хотят работать. -- http://absurdopedia.wikia.com/wiki/Haskell -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqnr3imb.wl%...@ran.pp.ru