NULL vs Empty при работе с пользовательским вводом

Ответ 1

Я почти никогда не использую NULL при обращении к фактическим данным. Когда используется для внешних ключей, я бы сказал, что NULL действителен, но почти никогда не действует для введенных пользователем данных. Единственное исключение, которое, вероятно, возникло бы довольно регулярно, - это даты, которые не существуют, например база данных сотрудников с полем "term_date". В этом случае все текущие сотрудники должны иметь значение NULL в этом поле. Что касается того, чтобы заставить их фактически вводить нулевое значение, для значений, которые действительно требуют нулевого значения, я бы поставил флажок рядом с полем ввода, чтобы пользователь мог его проверить и выключить, чтобы увидеть соответствующее значение null (или в более удобной для пользователя форме, нет). Если флажок установлен в поле null, соответствующее текстовое поле должно быть отключено, и если нулевое значение уже связано, оно должно начинаться как отключенное и включаться только после отмены флажка null.

Ответ 2

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

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

• Как вы его в алфавитном порядке?

• Можете ли вы однозначно определить, когда пользователь пропустил ввод значения, по сравнению с умышленным оставлением его пустым?

• Как бы вы однозначно запросили разницу? Может ли пользователь экрана запроса указать NULL void blank, используя стандартный синтаксис формы ввода?

• На практике мне никогда не запрещалось читать и писать данные с использованием стандартного, неудивительного поведения с использованием этого правила. Если мне нужно знать разницу, я использовал логическое поле (которое легче сопоставить с однозначными устройствами пользовательского интерфейса). В одном случае я использовал триггер для принудительного использования True = > null value, но никогда не видел его вызванным, потому что уровень BR эффективно отфильтровал это условие.

Ответ 3

Если пользователь предоставляет пустую строку, я всегда рассматриваю ее как нуль с точки зрения базы данных. Кроме того, я обычно подстраиваю свои строковые входы, чтобы удалить ведущие/конечные пробелы, а затем проверить на пустое. Это небольшая победа в базе данных с типами varchar(), а также уменьшает случаи поиска, так как мне нужно только проверить name is null вместо name is null or name = ''. Вы также можете пойти другим путем, преобразуя null в ''. В любом случае, выберите способ и будьте последовательны.

Ответ 4

Что вам нужно сделать, это выяснить, какое поведение вы хотите. Существует не одна фиксированная алгебра, как интерпретируются строки имен.

Подумайте о конечной машине здесь: у вас есть поля, которые имеют несколько состояний: это звучит так, как будто вы думаете о состоянии "унициализированного", другое - "целенаправленно пусто" и третье с некоторым заданным значением. НИЧЕГО вы делаете то, что делает это задание и согласуется с остальной частью вашей программы; это похоже на то, что легкое отображение

NULL → неинициализированным
"" → целенаправленно отменяется
имя → инициализируется.

Ответ 5

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

• Пустое имя
• Нулевое имя
• Непустое имя

Если вы перейдете с "blank is null" или "null is blank", то вы сократите до двух случаев. Два случая лучше, чем три.

Чтобы ответить на ваш вопрос: пользователь, вводящий данные, вероятно, не знает (и не должен) ничего знать о том, что такое "нуль" и как он сравнивается с "пустым". Эта проблема должна быть решена чисто и последовательно в системе, а не в пользовательском интерфейсе.

Ответ 6

В то время как ваш пример в основном для строк, мне нравится говорить, что я использую null для числовых и логических полей. Учетный баланс 0 очень отличается от меня, как тот, который равен нулю. То же самое для boolean, если люди берут тест с множественным выбором с истинными и ложными ответами, очень важно знать, ответил ли кто-то истинный или ложный или вообще не ответил. Не используя null в этих случаях, мне потребуется дополнительная таблица или другая настройка, чтобы узнать, ответил ли кто-либо на вопрос. Вы можете использовать для примера -1 для не заполненных 0 для false и 1 для true, но тогда вы используете числовое поле для чего-то, что по существу булево.

Ответ 7

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

Ответ 8

Я всегда использовал NULL для неинициализированных значений empty для целенаправленных пустых значений и 0 для выключенных индикаторов.

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

Обычно я тестирую empty(), но иногда я проверяю isset(), который оценивает false на NULL. Это полезно для напоминаний, чтобы ответить на некоторые вопросы. Если это empty, false или 0, тогда на вопрос будет дан ответ.