Re: Perl or Python?
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
Reply to: