Re: Perl or Python?
Hello!
Из дискуссии уже видно, что NULL (undefined) значения - трактовать
можно различным образом,
в зависимости от решаемой задачи. Соответственно, специалисты в разных
областях имеют разные трактовки.
Как пример: в поле БД sex значение равно NULL. Программист скажет -
ну, это же понятно, нет данных. А
биолог будет уверен - это гермафродит. Физик же будет рассматривать
эти записи как ошибки измерения. Таких
трактовок может быть много, главное же - мы не можем обработать
подобные записи, т.к. их смысл нам неизвестен.
Используя NULL значения, мы скрываем проблему, а при обработке
игнорируем поля с NULL или придумываем им
одну из возможных трактовок - в итоге в примере выше достоверно не
найдем ни гермафродитов, ни ошибочных
записей, ни записей с отсутствующей информацией (нетрудно догадаться,
что каждый программист будет
ошибаться по своему, подсчитывая вышеуказанные записи).
Что касается практики, то при наличии нескольких путей внесения данных
- через веб-формы, импорт
из сторонних систем и форматов - в каждом случае трактовка NULL может
отличаться, и это вдобавок к тому, что
NULL и так неоднозначен. Единственный однозначный способ разрешения
таких ситуаций - генерация ошибки
непосредственно при вводе данных и отказ от хранения неопределенных
значений. В интерактивном режиме можно
показать сообщение об ошибке, в пакетном - сохранить запись об ошибке
для дальнейшего просмотра (если
потребуется). Обработка таких ошибок требует заранее продумать
соответствующие действия. Современные
СУБД поддерживают целый ряд "костылей" для обработки NULL значений,
см. http://ru.wikipedia.org/wiki/NULL_(SQL)
В реальных системах бывает невозможно определить, корректно ли
обрабатываются NULL
значения (как правила предметной области, так и код приложений могут
изменяться, поди определи, что могут
значить NULL в старых записях, даже если изучить _текущие_ исходные
коды приложения).
И немного теории. Научный эксперимент требует измеримости и
воспроизводимости результатов. Неопределенные
значения по определению недопустимы :) Потому, кстати, язык тикль
(Tcl), созданный физиком Джоном Оустерхаутом
(John Ousterhout) для студентов-физиков, не имеет неопределенных
значений. NULL в теории реляционных БД был
добавлен Коддом для представления отсутствующих данных при внешних
соединениях (OUTER JOIN), а в
нормализованных таблицах значений NULL быть не может. Как вариант -
можно рассматривать значение NULL как
строку нулевой длины, так делается в tclsqlite при выборках из БД (а
при вставке NULL и пустая строка уже
различаются, по понятным причинам).
P.S. Напомню первый ответ Артема "А вариант с NULL может быть
оптимизацией, ЕСЛИ ЭТА ОПТИМИЗАЦИЯ
ДОКАЗАЛА СВОЮ НЕОБХОДИМОСТЬ." Добавлю - если не знаете, как доказать,
то и не используйте NULL.
--
Best regards, Alexey Pechnikov.
http://pechnikov.tel/
Reply to: