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