В SQL и Relational Theory (C.J. Date, 2009) глава 4 выступает за предотвращение дублирования строк, а также во избежание атрибутов NULL в хранящихся нами данных. Хотя у меня нет проблем, избегая повторяющихся строк, я изо всех сил пытаюсь понять, как я могу моделировать данные, не используя NULL. Возьмем, например, следующее: это немного от работы.
У нас есть таблица artist, которая имеет среди других столбцов столбец gender. Это внешний ключ таблицы gender. Однако для некоторых художников мы не знаем их пола - например, нам дали список новой музыки, в которой нет описаний художника. Как, без использования NULL, нужно ли представлять эти данные? Единственное решение, которое я вижу, - добавить новый пол "неизвестный" в таблицу gender.
В то время как я полностью наслаждаюсь этой книгой, я был очень разочарован, когда глава закончила:
Конечно, если nulls запрещены, то недостающая информация должна обрабатываться некоторыми другими способами. К сожалению, эти другие средства слишком сложны, чтобы подробно обсуждаться здесь.
Это настоящий позор - потому что это было решение, о котором я ждал, чтобы его прочитать! Существует ссылка на чтение приложения, в котором есть много публикаций для чтения, но я надеялся получить немного более подробное резюме, прежде чем я погрузился в их чтение.
Я получаю несколько человек, комментирующих, что они не понимают, почему я хочу избежать "NULL", поэтому я снова приведу книгу. Возьмите следующий запрос:
SELECT s.sno, p.pno
FROM s, p
WHERE s.city <> p.city
OR p.city <> 'Paris'
Теперь, возьмите пример, что s.city - Лондон, а p.city - Париж. В этом случае London < > Paris, поэтому запрос верен. Теперь рассмотрим случай, когда p.city не является Парижем, и является infact xyz. В этом случае (London < > xyz) OR (xyz < > Paris) также является True. Таким образом, с учетом любых данных - этот запрос является истинным. Однако, если xyz является "NULL", сценарий изменяется. В этом случае оба эти выражения не являются ни истинными, ни ложными, они на самом деле неизвестны. И в этом случае, потому что результат неизвестен, вы не получите никаких возвращенных строк.
Переход от 2-значной логики к 3-значной логике может легко вводить такие ошибки. Infact, я просто представил один на работе, который мотивировал этот пост. Мне нужны все строки, где type != 0 Однако это фактически заканчивается совпадением type == 0 OR type IS NULL - запутанного поведения.
Могу ли я моделировать свои данные с или без NULL в будущем, неясно, но мне очень любопытно, что такое другие решения. (Я тоже всегда был аргументом, что, если вы этого не знаете, вы должны использовать NULL).
