Нули в реляционной базе данных в порядке?

Question

Существует точка зрения, что нулевые значения не должны быть разрешены в реляционной базе данных. То есть атрибут таблицы (столбец) не должен разрешать нулевые значения. Исходя из опыта разработки программного обеспечения, я действительно не понимаю этого. Кажется, что если значение null допустимо в контексте атрибута, то это должно быть разрешено. Это очень распространено в Java, где ссылки на объекты часто бывают нулевыми. Не имея большого опыта работы с базами данных, мне интересно, что я что-то здесь упускаю.

Answer 1

Мое противоречивое мнение на сегодняшний день - по умолчанию разрешение NULL в столбцах базы данных было, вероятно, худшим общепринятым проектным решением во всех странах RDBM. Каждый продавец делает это, и это неправильно. NULL хороши в определенных, конкретных, хорошо продуманных случаях, но идея о том, что вы должны явно запрещать NULL для каждого столбца, делает небрежность обнуляемости более распространенной, чем должна быть.

Answer 2

Один вопрос, если вы используете базу данных Oracle. Если вы сохраните пустую строку в столбце с типом CHAR, Oracle принудительно вызовет значение NULL, не спрашивая. Поэтому может быть довольно трудно избежать значений NULL в строковых столбцах в Oracle.

Если вы используете значения NULL, научитесь использовать команду SQL COALESCE, особенно со строковыми значениями. Затем вы можете предотвратить распространение значений NULL на ваш язык программирования. Например, представьте человека с именами FirstName, MiddleName и FamilyName, но вы хотите вернуть одно поле;

  SELECT FullName = COALESCE(FirstName + ' ', '') + COALESCE(MiddleName+ ' ', '') + COALESCE(FamilyName, '') FROM Person

Если вы не используете COALESCE, если любой столбец содержит значение NULL , вы получите NULL возвращено.

Answer 3

ноль означает отсутствие значения, а 0 нет, если вы видите 0, вы не знаете значение, если вы видите ноль, вы знаете, что это пропущенное значение

Я думаю, что нули намного понятнее, 0 и '' сбивают с толку, так как они не ясно показывают цель сохраненного значения

Answer 4

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

Просто для того, чтобы сказать, как вы можете иметь имя, отчество, фамилию для каждого человека. (Отчество и Фамилия необязательно, тогда в этом случае NULL для вас) а также как вы можете иметь факс, рабочий телефон, офисный телефон для всех в списке блогов.

NULLS в порядке, и вы должны правильно обращаться с ними при поиске. В SQL Server 2008 существует концепция разреженных столбцов, в которой вы также можете избежать места, занятого для NULL.

Не путайте NULL с нулями и другими значениями. Люди делают то, что говорят, что это правильно.

Спасибо Нэвин

Answer 5

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

Answer 6

пустые камни. Если бы это не было необходимо в некоторых случаях, SQL не имел бы IS NULL и IS NOT NULL в качестве операторов особого случая. NULL является корнем концептуального универсального, все остальное НЕ NULL. Используйте NULL свободно, когда возможно, что значение данных отсутствует, но не пропущено. Значения по умолчанию могут компенсировать NULL, только если они абсолютно правильны все время. Например, если у меня есть однобитное поле «IsReady», может иметь смысл для этого поля иметь значение по умолчанию, равное false, и NULL не допускается, но это неявно утверждает, что мы знаем , что что бы не было готово, когда на самом деле у нас может не быть таких знаний. Скорее всего, в сценарии рабочего процесса человек, который решает, готов или не просто, еще не имел возможности высказать свое мнение, поэтому значение по умолчанию false может быть опасным, что заставит его не принимать решение, которое, по-видимому, имеет был сделан, но на самом деле был только дефолт.

в качестве отступления и со ссылкой на пример среднего инициала у моего отца не было отчества, поэтому его средний инициал был бы НЕДЕЙСТВИТЕЛЕН - не пробел, пробел или звездочка - за исключением армии, где его средний инициал был NMI = Нет среднего начального Как глупо это было?

Answer 7

Лично я считаю, что значения NULL следует использовать только при использовании поля в качестве внешнего ключа для другой таблицы, чтобы символизировать, что эта запись не связана ни с чем в другой таблице. Кроме этого, я считаю, что нулевые значения на самом деле очень проблематичны при программировании логики приложения. Поскольку в большинстве языков программирования отсутствует прямое представление нулевой базы данных для многих типов данных, в конечном итоге создается большое количество кода приложения, чтобы понять значение этих нулевых значений. Когда БД встречает нулевое целое число и пытается, например, добавить к нему значение 1 (иначе ноль + 1), база данных возвратит ноль, как это определяется логикой. Однако, когда язык программирования пытается добавить нуль и 1, он обычно выдает исключение. Итак, ваш код в конечном итоге завален проверками того, что делать, когда значение равно нулю, что часто просто равнозначно преобразованию в 0 для чисел, пустой строке для текста и некоторой нулевой дате (1900/1/1?) Для полей даты .

Answer 8

Я думаю, что вопрос сводится к тому, что вы интерпретируете значение NULL для обозначения. Да, существует множество интерпретаций для значения NULL, однако некоторые из них, размещенные здесь, никогда не должны использоваться. Истинное значение NULL определяется контекстом вашего приложения и никогда не должно означать больше, чем одно. Например, одно предположение заключалось в том, что значение NULL в поле даты рождения будет указывать на то, что человек еще жив. Это опасно.

Для простоты определите NULL и придерживайтесь его. Я использую его для обозначения «значение в этом поле неизвестно в настоящее время». Это означает, что ТОЛЬКО это. Если вам нужно, чтобы это означало что-то еще, КАК ХОРОШО, тогда вам нужно пересмотреть свою модель данных.

Answer 9

Как аналитик / программист с 30-летним опытом, я просто скажу, что NULL должны быть возвращены и избавлены от их страданий.

-1, 01/01/0001/12/31/9999 и? все будет достаточно и без искажающего разум кода, необходимого для того, чтобы справиться с этими неприятными NULL.

Answer 10

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

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

Это очень распространено в Java, где ссылки на объекты часто бывают нулевыми.

Есть школа мысли, которая говорит, что нулевые ссылки там тоже плохие . Та же проблема: что означает нуль означает ?

IIRC, Java имеет как "null", так и "неинициализированный" (хотя для последнего нет синтаксиса). Таким образом, Гослинг понял, что глупо использовать «ноль» для каждого вида «нет значения». Но зачем останавливаться на только на двух ?