У некоторых людей это религиозное. В духе известного анекдота про обрезание сосисок.

Это довольно странная точка зрения. Во всяком случае, мне было бы интересно, как Вы сумеете сформулировать принципиально различные определения "значения" и "индикатора отсутствия значения", учитывая, что и то, и другое в конечном итоге - набор битов.


Это всего лишь означает, что не нужно использовать Clear не по назначению, а нужно кроме Clear иметь метод SetNull (и по правде говоря, при его наличии трудно придумать, зачем нужен Clear).

Ну а после отказа от карго-культа и SetNull становится маловажным, поскольку в 99% случаев более уместен .AsString := ''.

Конечно. Логика для нуля и для пустой строки существенно различна. Но в том, что Вы цитируете, я не об этом. Я примерно вот о чём: допустим, я написал СУБД, в ней таблица с одной колонкой, в ней две записи. Вот эти записи в битовом представлении:


Дополнительная информация: в одной из этих записей лежит значение null, в другой - буква "я". Мне очень интересно, каким образом коллега установит, где "значение", а где - "индикатор отсутствия значения", и, соответственно, ответит, какая из этих двух последовательностей битов какому значению соответствует.

У null значение null. Интерпретация этого значения зависит от бизнес-логики в конкретном случае.


Докажите.

Насколько я видел данности мира SQL, в нём есть следующие варианты:

1. Пустая строка и null неразличимы. Это удобно, соответствует логике реального мира и заметно облегчает жизнь.
2. Пустая строка и null различимы. Это неудобно, не соответствует логике реального мира и создаёт дополнительные проблемы.
2.1 Разработчик выносит на уровень внутреннего стандарта использование везде одного из этих двух значений. Например, вешает на все строковые поля constraint check (value <> ''). В результате приемлемым количеством геморроя он приводит ситуацию к первому пункту, исправляя кривизну БД.
2.2 Разработчик этого не делает, и через несколько лет все окружающие имеют большое сексуальное удовольствие сопровождать систему, в которой в половине мест "отсутствие значения" индицируется null-ом, в другой половине мест "отсутствие значения" индицируется пустой строкой и при написании кода каждые пять минут следует лазить в структуру таблиц смотреть как оно в конкретном поле, выбирать соответствущие операции и обвешивать всё многочисленными страховками.

Null - это ровно такое же "определённое значение с точки зрения программирования".


И null для неё тоже - одно из допустимых значений.


Конечно.

Мы ничего не должны, но чем больше реализация будет соответствовать потребностям реального мира, тем лучший результат будут выдавать те же программисты.

В случае чисел, по моему опыту, оптимальный подход - различать null и 0, но при этом доопределить арифметические операции следующим образом:

- деление любого числа на 0 даёт null
- сложение и вычитание числа с null-ом даёт результатом это число.

И да, этот подход проверен на практике, и результаты очень хороши.


Хороший вопрос. У меня нет на него однозначного ответа. У их различия есть свои плюсы, у их неразличимости - свои, и я не возьмусь уверенно сказать, какие весомее. Пожалуй, я бы сказал так: если ориентироваться на квалифицированных разработчиков, их лучше различать, если на неквалифицированных - лучше было бы не различать.


Я практически не работал с guid и могу чего-то не знать, но не вижу причин выносить его в особый тип. Думаю, будет правильно, если в отношении него будут действовать ровно те же правила, что и для соответствующего ему строкового значения.


К строкам нет никакого особого отношения. Отношение везде одно - соответствие логике реального мира.

Если Вы хотите спросить, почему для нуля и пустой строки разные оптимумы, то возьмите два листа чистой бумаги формата А4. Напишите на первом из них цифру 0 и скажите, можете ли Вы отличить этот лист от второго. Теперь возьмите ещё два листа чистой бумаги формата А4, напишите на третьем пустую строку и скажите, можете ли Вы отличить его от четвёртого.

Они понятны не из соображений "здравого смысла", а из соображений "стройности математической теории".


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