On Fri, 20 Mar 2009 16:35:24 +0300 Alexey Pechnikov wrote: > > Извиняйте, что вклиниваюсь, но мне не совсем понятна спасительность > > метода в данном конкретном случае. Из того, что "во второй таблице > > не будет записей" _всё равно_ совершенно непонятно, "следует ли > > платить Витусу за измерение температуры в этот день", разумеется, > > если это не сдельная оплата "за строчку таблицы". > > Если есть запись во первой таблице, то платить (замер был > произведен), если нет, то не платить. Отсутствие записи во второй > таблице сообщит нам, что измерение выполнить не удалось (но попытка > была сделана). Если вернуться к первому посту Владимира, то очевидно, пьяному синоптику надо платить )). Сори, вырвалось. > > > А при выяснении "то ли он весь день читал Лукьяненко и забыл > > смерить температуру, то ли температуру мерять ходил, но в силу > > объективных причин данных не получил" СУБД вряд ли поможет.... > Как видите выше, поможет. Принцип понятен, но.
> > > База с использованием NULL это так назваемая "удобная для > > > заполнения" база. Для анализа она непригодна, так как потеряно > > > много важной информации о данных, в частности, невозможно > > > различить невалидные и отсутствующие данные. > > > > Насколько я понял, Владимир предложил не писать вообще ничего там, > > где другие напишут NULL - как в случае отсутствия (медведь съел), > > так и в случае невалидности (градусник замёрз) данных. Вряд ли это > > поможет нам различать такие данные. > > Дело в том, что реляционная модель работает с кортежами - строками в > таблице. И правильно будет или писать кортеж, или не писать. А вот > создавать некий флаг (NULL это не значение, а некий флаг) в одном из > атрибутов неверно идеологически и, как мы видели, приводит к > неоднозначности. Насчёт идеологии возражений в принципе нет, но это лишь теория. В рассматриваемом примере я вижу взаимно однозначное соответствие NULL-евых и не-NULL-евых вариантов (разумеется. при _правильном_ заполнении базы синоптиком), и бОльшей неоднозначности ни в одном из них я не нахожу. > А вариант с декомпозицией поможет различить > отсутствие измерения (нет записи в таблицах 1 и 2) и отсутствие > результата измерения (есть запись в таблице 1 и нет записи в таблице > 2) Ввиду очевидности не буду писать, как отличать эти события в NULL-евой базе. > Зато интерпретация данных в базе не будет > зависеть от личных предпочтений прикладного > программиста/пользователя. Действительно, _иногда_ ГД может быть весьма наглядна. Но имхо личные предпочтения программиста - это использовать или нет NULL. Хорошо если оный программист умеет писать всяко и инструмент подбирает исходя из задачи, а не руководствуясь личными предпочтениями. > К счастью, вышеописанный способ не > единственный, хотя зачастую без него не обойтись. Уверен, многие обходятся (на всякий случай: я имею ввиду не тех, которые обходятся без компьютера). ------ Grey Fenrir -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
