Что говорит реляционная теория про NULL-значения?

Тег упорин добавь

Так не бывает, сделай поле обязательным(NOT NULL) и не надо будет ничего гарантировать, только TRUE или FALSE :)

Да вчера на собеседовании с каким-то чмом поспорил, он аж трубку бросил. От null же одни проблемы?

Что говорит реляционная теория про null значения?

Что то мне подсказывает что null значения в самой реляционной алгебре не фигурировали. Иначе как можно объяснить генерацию 1:n может:должен через слабую сущность. Вот в этом случае, к примеру, nullable fk очень полезен. Ибо много что упрощает.

От null же одни проблемы?

Где от null проблемы - ставишь not null.

Причем здесь непротиворечивость? Null полезная штука для индикации отсутствия значения. Логика в реляционной алгебре троичная, никаких противоречий это не вызывает. Проблема с нулами в том, что они не индексируются (значения то нет), и использование троичной логики контринтуитивно.

Иначе как можно объяснить генерацию 1:n может:должен через слабую сущность. Вот в этом случае, к примеру, nullable fk очень полезен.

Не в курсе, что это. Расскажи.

Я вижу, ты нмнго лучше меня в этом разбираешься. Расскажи что такое консистентность.

Пардон, может:может. Чуть попозже объясню что помню

Просто для каждой сущности и атрибута нужно ввести доп. поле существования.

Хотя, для атрибута вроде не надо, хз.

Правило номер один: использовать те средства, которые максимально лучше решают задачу. NULL, value, «» это не логика, логика это ENUM.

Правило номер два: NULL следует избегать или приветствовать, ибо это определяет тип индексации. Разряженный индекс vs неразряженный.

Правило номер три: разряженный индекс мало чем отличается от неразряженного, но без уникальных значений.

Вывод, там, где имеется индекс по неуникальному значение равносилен индексу, где имеет место быть значение типа NULL. Т.о. для БД не играет роль смысл значения. Смысл играет роль для людей, которые пишут код. Поэтому, тот кто считает, что якобы NULL нужно избегать — полный профан. Задай своему мастеру сколько места занимает в БД значение NULL, сколько ENUM, и сколько 1 и 0. Как только выяснишь эту истину — сможешь поставить на колени любого умника :)

гарантировать непротиворечивость

Мне кажется, что «неизвестно», в отличии от любых других значений, не способно противоречить чему бы то ни было. Т.ч. с противоречивостью, как раз, проблем меньше всего.

Единственное неудобство — внешнее соединение (OUTER JOIN). При возможности незаполненных значений (NULL) мы не можем узнать, то ли строка не найдена, то ли нашлась с незаполненным значением.

Обычно под констстентностью имеют в виду, что все последующие за записью чтения видят то, что было записано. Тут еще был термин противоречивость. В контексте рсубд это нарушение реляционой аксиоматики, что может быть в случае багов в реализации

если проектировать данные по Дэйту, то первым делом ты должен декомпозировать свои отношения. Делается это с помощью двух инструментов: 1) реляционная алгебра 2) ER- модели(у нас она известна как логическая модель БД). Причем делать ты можешь это как декомпозируя «плоское отношение» из всех сущностей предметной области, так и накидав модельку на глаз и её уже до НФБК доводить (вопрос к присутствующим: кто-нибудь так делает в трудовой деятельности, а 5НФ и выше пользует?).

2 инструмента надо вот зачем: реляционная алгебра определяет функциональные зависимости(1 аргумент - 1 значение). А ER-модель побогаче в этом плане и ближе к физической модели данных. Отношения в ER-моделях бывают:

По модальности

• может - может. Пример: У тебя может быть тня, а у тни может быть кун. А может и не быть.
• может - должен. Пример: Ты можешь косить от армии, но в армии должен быть хотя бы один ты.
• должен - должен. Пример: У тебя должна быть игра, а у игры должен быть создатель.

По мощности(за терминологию в этом случае не ручаюсь)

• 1:1. Пример: ты один живешь в демократическом государстве, у которого дожен быть один президент. А у одного президента должно быть одно государство.
• 1:n. Пример: у тебя есть одна родина, а у родины таких робят мильёны
• m:n. Пример: на наших чиновников наложены санкции разный стран, каждая санкция распространяется на список чиновников.

Ну и каждое отношение обладает как модальностью так и мощностью. В общем ты когда ER модель построил, отдекомпозировал все, пора от логической модели переходить к физической. Ну типы данных определять(вообще это и раньше где-то делается, доменами называются, но домены это такая очень крутая система типов, а в СУБД есть int, double, varchar и тому подобные примитивы), ключики расставлять, сурогатные ключи(id) вводить.

На этом этапе и появляются правила генерации. Они простые.

• 1:1 должен - должен: вообще не трогаем, потому как это в табличке с возможным ключем лежит.
• 1:1 может - должен, 1:n должен - должен: таблица 1 {id, val1,val2}, таблица 2 {id,val3}. ID 2 таблицы должен быть foreign key и сылаться на table1.id
• 1:n может - должен. Решается просто внешним ключиком.
• 1:n может-может, n:m, 1:n - может может - строим слабую сущность. table1{id,val}; table2{id,val}; weak{a:fk->table1.id, b:fk->table2.id, pk:(a,b)}

Вот и смотри, в случае 1:n может может, вместо генерации трех таблиц можно просто сделать fk NULL. А почему правило такое не сделают? а потому что когда-то null не было как такого у теретиков. Эта вся тирада была именно к этому, null - просто инструмент, бывает полезен. Почему по умолчанию в известных мне СУБД не NOT NULL - хз

NULL не противоречит ни true, ни false, поскольку является допустимым. Результат проверки консистентности тоже вполне логично определять этими тремя значениями.
Или у тебя троичная логика вызывает неконсистентность мировосприятия?

Разряженный индекс vs неразряженный.

У того же postgres есть индексы по условию, так что мимо

Например:

Category:
  id: int
  name: string
  parent_id: int null

Если parent_id = null, значит корневая категория.

К. Дж. Дейт, «Введение в системы баз данных». Очень рекомендую.

Глава 19, «Отсутствующие значения»:

неопределенные значения (NULL) И трехзначная логика являются ошибочными понятиями и им нет места в четких формальных cистемах, подобных реляционной модели

...

даже сама попытка точно определить, что собой представляет схема, в которой применяются неопределенные значения, позволяет сразу же показать, почему идея неопределенных значений не совсем обоснована. Вследствие этого ее также трудно достаточно логично объяснить. Как указано в [11.10], «она приобретает хоть какой-то смысл, только если вы на многое закрываете глаза и не слишком утруждаете себя размышлениями».

И т.д.

вчера на собеседовании с каким-то чмом поспорил

Ящетаю это к лучшему

Что говорит реляционная теория про NULL-значения?

Есть два подхода:

1. NULL не тру и ошибка природы.

2. NULL тру и без него рел. базу не сделаешь.

На текущий момент этот спор уже спец. олимпиада. Реальность: NULL - в реальных бд есть, но везде достаточно кастрированный ибо честный null очень не удобен.

Пример Оракл: " (пустая строка) эквивалентен null

select length('') from dual; -- результат NULL
exec test_bool( 'a' != '' ); -- UNKNOWN; ну и т.п. чудеса

В общем простого ответа нема и с NULL не просто, без него тоже не просто.

Поэтому, тот кто считает, что якобы NULL нужно избегать — полный профан.

Не будь так категоричен. http://ru.wikipedia.org/wiki/Дейт,_Кристофер считает, что NULL быть не должно.

Спасибо. Я половину не понял, поэтому - порекомендуй книгу :)

Дэйт решал задачу по переносу почти всех ограничений предметной области на схему данных. У тебя же не такая задача.

Спасибо, дружище. Где ты это прочёл? Я хочу тоже.

Я прочёл только две книги (хороших, к счастью), большая часть сообщений в треде мне непонятна.

Где ты это прочёл? Я хочу тоже.

в универе на 3м курсе узнал. Дэйт, Конолли, из литературы.

man Дейта

Таненбаум распределенные системы

В общем простого ответа нема и с NULL не просто, без него тоже не просто.

С null непросто в основном потому, что null не подвергается операциям сравнения (есть только is [ not] null), но без null вообще песец - пример уже приводили - древовидные структуры. Можно конечно извернуться и объявить дерево графом и хранить его в структуре графа (nodes/paths), но это часто идет вразрез с производительностью.

у тебя кашка

N/A всегда не равно себе .

а арифметика в которой есть NaN ( а N/A и есть логическое NaN - т.е если ригористично Not a Boalean)

вот и всё.

для NaB законы де моргана и прочии правила приобретают несколько парадоксальный(для поверхностного взгляда) характер

Есть практика, есть теория. Истина возникает там, где теория сталкивается с практикой. Поскольку NULL это частный случай какого-то значения, а не вообще ничего или пустой строки (она кстати тоже значение, в самом простом виде это \0), то Дейт прав в том, что эта лишняя сущность. С другой стороны, если рассматривать NULL как противовес заполненному полю неважно какого значения, то получается, что он полезен: select * from t1 where col1 is not null. Т.о. имеем NULL (false) и что-то (TRUE).

Что касается реальности и имплементации булевой логики, то либо берут ENUM, либо INT (с поправкой на использование), либо CHAR/ENUM. Касательно проблемы с JOIN тут уже мелькало, кстати, весьма распространенное явление.

И имеется вопрос индексации, который также отвечает за практическую составляющую, о чем я говорил выше.

Поэтому те, кто начинает с тобой философствовать в ключе нужен ли NULL в БД ожидают, что ты понимаешь в чем загвоздка и надеются, что ты вундеркинд и сможешь решить вопрос как избавиться от NULL. К сожалению, от него никак не избавиться, потому что в противном случае нужно создавать другую вариацию NULL: is exists. И к счастью, БД может и не идельна, человек может заставить все работать как надо: ENUM, устные условия (хардкод) и т.п.

Поскольку NULL это частный случай какого-то значения, а не вообще ничего или пустой строки

что?

и надеются, что ты вундеркинд и сможешь решить вопрос как избавиться от NULL.

ну так от него избавляться же не составляет труда, но зачем?

Вообще, если по уму, пустое значение определенного типа должно входить в домен данного типа. И тогда никакого противоречия не будет. И вообще, типы надо сразу задавать в таком виде:

CREATE TABLE abc_table(
a INT where a<5 and a>0 with Empty[Int];
b VARCHAR(3) where b in ('ABC'|'CBA');
c INT {IF a isEmpty 0 else a>c})

что?

NULL это значение. Изучи введение по си и поймешь почему это значение, а не что ты там себе выдумал. Именно поэтому индекс по полю UNIQUE, где разрешен NULL строится идеально, и БД не говорит, что это невозможно.

пустое значение определенного типа должно входить в домен данного типа

Это называется DEFAULT. То, что ты привел это смысл (придуманный человеком), который лежит за пределами компетенции БД. Иными средствами это решается через PL/SQL и т.п. решения.

вот тогда будет очень круто.

Круто не городить костыли там, где им не положено быть. Делай тоже самое на стороне приложения, либо получай вагон и тележку в минус производительности БД.

NULL это значение

Кстати да - было дело, в запросе фигурировал ORDER BY fld которое таки могло быть NULL, и что же мы увидели? В посгре NULL - это самое большое значение, а в мускуле - самое маленькое.

Хоар до сих пор страдает , что битовое представление NULL совпадает с последовательностью(некоторой длины как функции машинки и конфы) битов из только off

и ты различаеш же представление NULL и его семантику?

второе есть N|A

второе есть N|A

И? Выше, я уже говорил почему он нужен.

NULL это значение.

ты говорил «частный случай значения», вот я и не понял.

Это называется DEFAULT

DAFAULT - это значение по умолчанию, а null - пустое значение. 0!=null для INT, к примеру. Что оно одно на все типы - это вообще не есть правильно, но не особо мешает.

Круто не городить костыли там, где им не положено быть.

контролю за консистентностью данных - место в субд. То что я показал уже есть, в MS SQL, к примеру, check constraints называется. Но я таки говорил про концептуальную крутость и производительности не касался.

Делай тоже самое на стороне приложения

Где можно такие типы делать?

http://www.amazon.com/Introduction-Database-Systems-8th-Edition/dp/0321197844

http://www.amazon.com/Transaction-Processing-Concepts-Techniques-Management/d...

обе две покрывают тему с разных сторон (первая - теория, вторая имплементация), жутко нудные. Под впечатлением от второй Heikki написал свой innodb, без которого mysql бы никогда не взлетел.

И вообще, типы надо сразу задавать в таком виде:
...

http://www.postgresql.org/docs/devel/static/ddl-constraints.html

если следовать твоей логике то option/maybe type не нужны

Книги советуй, дружище)

Дейт очень сильно баттхертил по поводу NULL. Действительно говно то еще. Был бы нужен опциональный тип скорее.

option/maybe type не нужны

А там сваливается в общий домен? И где необходимость «троичной» логики на option.

Они как раз нужны. А NULL - нет. Ибо костыль и говно.

для NaB законы де моргана

А можно поподробнее: что там изменилось-то?

закон исключённого третьего?

закон исключённого третьего?

Только два закона де Моргана знаю, это какой-то из них или еще есть?

был не точен,

мне что формулы де Моргана , что исключённое третье асоциированны с булевскими преобразованиями ( ну или с множествами ) - однако наличие N|A делает некоторые цепочки преобразований ложными.