MySQL, лучше вставить NULL или пустую строку?

198

У меня есть форма на веб-сайте, где есть много разных полей. Некоторые из полей являются необязательными, а некоторые являются обязательными. В моей БД у меня есть таблица, которая содержит все эти значения, лучше ли вставлять значение NULL или пустую строку в столбцы БД, где пользователь не помещал какие-либо данные?

Теги:

6 ответов

190
Лучший ответ

Используя NULL, вы можете различать "put no data" и "put empty data".

Еще несколько отличий:

  • A LENGTH of NULL - NULL, a LENGTH пустой строки - 0.

  • NULL сортируются перед пустыми строками.

  • COUNT(message) будет считать пустые строки, но не NULL s

  • Вы можете искать пустую строку с использованием связанной переменной, но не для NULL. Этот запрос:

    SELECT  *
FROM    mytable 
WHERE   mytext = ?

    никогда не будет соответствовать NULL в mytext, независимо от того, какое значение вы передадите от клиента. Чтобы соответствовать NULL s, вам придется использовать другой запрос:

    SELECT  *
FROM    mytable 
WHERE   mytext IS NULL
Поделиться
  • 2
    но какой из них вы думаете, быстрее? 0 или NULL или ""
  • 3
    @aadravid: нет разницы.
Показать ещё 10 комментариев
37

Одна вещь, которую следует учитывать, если вы когда-либо планируете переключение баз данных, заключается в том, что Oracle не поддерживает пустые строки, Они автоматически преобразуются в NULL, и вы не можете запрашивать их, используя предложения типа WHERE somefield = ''.

Поделиться
  • 11
    Это звучало невероятно подозрительно, даже по вашей ссылке, поэтому я попробовал. Пустое поле, установлено в '', оракул игнорирует его. Длина отчета как ноль, а не 0. Это просто так неправильно. Должен быть какой-то способ обойти это. Думаю, я опубликую это как еще один вопрос.
  • 1
    Steve B. .: см. Этот вопрос: stackoverflow.com/questions/1171196/…
Показать ещё 4 комментария
7

Следует иметь в виду, что NULL может сделать ваши кодеки намного сложнее. В Python, например, большинство адаптеров базы данных /ORM отображают NULL - None.

Итак, такие вещи, как:

print "Hello, %(title)s %(firstname) %(lastname)!" % databaserow

может привести к появлению "Hello, None Joe Doe!" Чтобы этого избежать, вам нужно что-то вроде этого кода:

if databaserow.title:
    print "Hello, %(title)s %(firstname) %(lastname)!" % databaserow
else:
    print "Hello, %(firstname) %(lastname)!" % databaserow

Что может сделать вещи намного сложнее.

Поделиться
  • 25
    По моему мнению, злоупотребление вашей базой данных для «исправления» ошибок в вашем коде или среде является (очень) плохой практикой кодирования. Когда данных нет, вы должны просто вставить NULL и быть последовательными в их использовании. В противном случае вы должны использовать такие выражения, как: if (myString == null || myString = ""). Когда объект не установлен или не определен в вашем коде, вы также используете NULL вместо какого-то «заполнителя» (который, на мой взгляд, является пустой строкой).
  • 5
    Очень зависит от вашего языка. В Python «если не myString:» тесты для None и «». Вероятно, в основном это культурные проблемы. «Плохая практика» Java Guys - это элегантность динамичного человека.
4

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

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

Смотрите также: Может ли внешний ключ быть NULL и/или дублироваться?

Поделиться
  • 0
    В прошлом проблема с ограничениями привела меня в замешательство, поэтому я «+1» ответил на этот вопрос.
3

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

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

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

Поделиться
  • 1
    ... И теперь, когда я вижу ответ выше меня, я думаю, что можно с уверенностью сказать, что обычное различие, о котором вы заботитесь, - это не данные, а пустые данные. :-)
0

Я не знаю о производительности. Но с точки зрения качества данных, null - это плохо.

Null дает вам тип maybe, который заставляет вас писать проверку типа времени выполнения, например: something = a.b.c.d.something if exist?(a) && exist?(a.b) && exist?(a.b.c) && exist?(a.b.c.d) && exist?(a.b.c.d.something).

Эта проблема может быть уменьшена, если вы не используете форматы json/hash/array.

Но да, допустимость null - ошибка в миллиард долларов.

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню