[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Perl or Python?



On Sat, 21 Mar 2009 00:59:57 +0300
Alexey Pechnikov wrote:

> On Friday 20 March 2009 22:16:19 Grey Fenrir wrote:
> > Насчёт идеологии возражений в принципе нет, но это лишь теория.
> > В рассматриваемом примере я вижу взаимно однозначное соответствие
> > NULL-евых и не-NULL-евых вариантов (разумеется. при _правильном_
> > заполнении базы синоптиком), и бОльшей неоднозначности ни в одном из
> > них я не нахожу.
> >
> > > А вариант с декомпозицией поможет различить
> > > отсутствие измерения (нет записи в таблицах 1 и 2) и отсутствие
> > > результата измерения (есть запись в таблице 1 и нет записи в
> > > таблице 2)
> > Ввиду очевидности не буду писать, как отличать эти события в
> > NULL-евой базе.
> И в чем эта очевидность заключается? 
"отсутствие измерения - нет записи в таблице"
"отсутствие результата - в поле результата NULL"

> Вот смотрите, что получается при следующем шаге индукции:
> Мы рассматривали 1 таблицу с NULL и декомпозицию из 2-х таблиц,
> содержащие записи о
> 1) измерение проводилось или не проводилось
> 2) результат получен или не получен
Насколько я понял, в случае, когда "измерение не проводилось" никаких
записей ни в одной таблице не содержится (как в NULL так и не-NULL
вариантах). Если я ошибся - буду рад узнать, где именно.
> 
> Чтобы наша задачка была ближе к реальности, добавим:
> 3) измерение обязательно или не обязательно
Если это и приблизит нас к реальности, то только к "суровой российской".
Потому "обязательность" либо известна заранее для всех измерений
данного прибора (и вводить её как параметр для каждого измерения я
смысла не вижу) либо [внятный] алгоритм её выяснения возможно переложить
на плечи системы обработки измерений (то есть с конечного пользователя
на программу, что безусловно есть гут). 
В любом случае, для приближения к реальности сначала следует описать
оный алгоритм, а потом обсуждать надо ли под такой признак отдельная
таблица. Другими словами, вряд ли заказчик может требовать ГД и три
таблицы. У него есть конкретная задача и пока я не пойму его логику
- говорить о внутренней архитектуре БД я смысла не вижу. Возможно,
именно это и имели ввиду ребята говоря о излишней теоретизации вопроса.
> 
> Теперь посмотрим, как мы должны сохранить в БД информацию о следующих 
> ситуациях:
> А) Измерение не проведено И результат не получен И измерение
> обязательно. Б) Измерение проведено И результат не получен И
> измерение не обязательно.
> 
> Вопрос:
> Что вы будете писать в _одну_ таблицу, допускающую NULL? Сколько
> вариантов ответа на этот вопрос существует? (Подсказка: 2 варианта
> ответа для А и столько же для Б). 
> 
> Решение:
> Анализируем условия слева направо:
> А) Измерение не проведено - запись не делаем.
> Б) Измерение проведено И результат не получен - делаем запись с NULL.
> 
> Анализируем условия справа налево:
> А) Измерение обязательно И результат не получен - делаем запись с
> NULL. Б) Измерение не обязательно И результат не получен - запись не
> делаем.
> 
> Как видим, ассоциативность нарушена, то есть проделанные вычисления
> не могут быть выполнены в рамках булевой алгебры. А это означает
> некорректность БД.
> 
> При использовании декомпозиции существует единственный вариант
> заполнения трех рассматриваемых нами таблиц. 

------
Grey Fenrir


Reply to: