Re: Perl or Python?
Hello!
On Saturday 21 March 2009 07:47:22 Grey Fenrir wrote:
> Если это и приблизит нас к реальности, то только к "суровой российской".
> Потому "обязательность" либо известна заранее для всех измерений
> данного прибора (и вводить её как параметр для каждого измерения я
Как пример можно рассмотреть систему анкетирования. Если опрос проводится
среди сотрудников компании-заказчика, то ответ обязателен. А вот партнеры
компании-заказчика могут отказаться отвечать на вопросы; разумеется, в отчетах
необходимо будет видеть список "нелояльных" партнеров. Это лишь один из
примеров, на практике условие обязательности измерения актуально в очень
многих задачах.
> смысла не вижу) либо [внятный] алгоритм её выяснения возможно переложить
> на плечи системы обработки измерений (то есть с конечного пользователя
> на программу, что безусловно есть гут).
Для проектировщика БД "пользователем" обычно является программист, который
будет писать приложение для работы с этой БД. Если отношения между данными
определяются однозначно, то и программисту работать намного легче, и данными
он будет оперировать корректно. Разумеется, архитектор БД и программист могут
быть одним и тем же человеком.
> В любом случае, для приближения к реальности сначала следует описать
> оный алгоритм, а потом обсуждать надо ли под такой признак отдельная
> таблица.
Совершенно верно. Но, как мы видели в обсуждении выше, многие разработчики
твердо уверены, что над этим и думать не надо, а стоит лишь распихать NULL по
полям таблиц. Я постарался показать, что это ошибочный подход и зачастую
приводит к неоднозначности и , следовательно, некорректности БД. Для
атрибутов, представляющих собой внешние ключи, использование NULL и оправдано
и необходимо, в отличии от атрибутов, хранящих значения, где NULL
предпочтительно не использовать во избежание неоднозначности.
На мой взгляд, правильным является начинать проектирование от базы без NULL и
только при необходимости разрешать NULL _только для внешних ключей_.
Кроме того, при использовании динамических языков, например, тикля, и СУБД без
строгой типизации применима практика замены NULL на пустую строку, что
позволяет получить взаимно-однозначное соответствие атрибутов БД и значений
переменных используемого языка. Конечно, это не более чем приведение NULL к
строковому типу, согласно парадигме "все есть строка" и непосредственно к
проблеме NULL-значений в SQL отношения не имеет.
Best regards.
Reply to: