Re: Perl or Python?
Hello!
On Friday 20 March 2009 14:18:34 Grey Fenrir wrote:
> On Thu, 19 Mar 2009 22:32:25 +0300
>
> Alexey Pechnikov wrote:
> > On Thursday 19 March 2009 21:36:47 Владимир Ступин wrote:
> > > Я ни в коей мере не спец по БД, но мне почему-то кажется, что
> > > необходимость прибегать к значениям NULL говорит о непродуманной
> > > структуре БД.
> >
> > Описанный вами метод известен как горизонтальная декомпозиция и
> > является одним из лучших вариантов решения проблемы с NULL. Для "не
> > спеца" неплохо :-)
>
> Извиняйте, что вклиниваюсь, но мне не совсем понятна спасительность
> метода в данном конкретном случае. Из того, что "во второй таблице не
> будет записей" _всё равно_ совершенно непонятно, "следует ли платить
> Витусу за измерение температуры в этот день", разумеется, если это не
> сдельная оплата "за строчку таблицы".
Если есть запись во первой таблице, то платить (замер был произведен), если
нет, то не платить. Отсутствие записи во второй таблице сообщит нам, что
измерение выполнить не удалось (но попытка была сделана).
> А при выяснении "то ли он весь день читал Лукьяненко и забыл
> смерить температуру, то ли температуру мерять ходил, но в силу
> объективных причин данных не получил" СУБД вряд ли поможет....
Как видите выше, поможет.
> > База с использованием NULL это так назваемая "удобная для заполнения"
> > база. Для анализа она непригодна, так как потеряно много важной
> > информации о данных, в частности, невозможно различить невалидные и
> > отсутствующие данные.
>
> Насколько я понял, Владимир предложил не писать вообще ничего там, где
> другие напишут NULL - как в случае отсутствия (медведь съел), так и в
> случае невалидности (градусник замёрз) данных. Вряд ли это поможет нам
> различать такие данные.
Дело в том, что реляционная модель работает с кортежами - строками в таблице.
И правильно будет или писать кортеж, или не писать. А вот создавать некий флаг
(NULL это не значение, а некий флаг) в одном из атрибутов неверно
идеологически и, как мы видели, приводит к неоднозначности. А вариант с
декомпозицией поможет различить отсутствие измерения (нет записи в таблицах 1
и 2) и отсутствие результата измерения (есть запись в таблице 1 и нет записи в
таблице 2) - мы можем реализовать сколь угодно многозначную логику, используя
требуемое число дополнительных таблиц.
Да, на практике этот способ сложнее, поскольку придется использовать большее
число таблиц. Зато интерпретация данных в базе не будет зависеть от личных
предпочтений прикладного программиста/пользователя. К счастью, вышеописанный
способ не единственный, хотя зачастую без него не обойтись. Еще один широко
распространенный метод состоит в хранении в атрибутах (полях БД)
сериализованных структур данных.
Best regards.
Reply to: