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

Ответ 1

Используя 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

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

Ответ 3

Следует иметь в виду, что 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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

Ответ 6

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

COLUMNS IN A UNIQUE INDEX:
(event_type_id, event_title, date, location, url)

EXAMPLE 1:
(1, 'BBQ', '2018-07-27', null, null)
(1, 'BBQ', '2018-07-27', null, null) // allowed and duplicated.

EXAMPLE 2:
(1, 'BBQ', '2018-07-27', '', '')
(1, 'BBQ', '2018-07-27', '', '') // NOT allowed as it duplicated.

Вот несколько кодов:

CREATE TABLE 'test' (
  'id' int(11) unsigned NOT NULL AUTO_INCREMENT,
  'event_id' int(11) DEFAULT NULL,
  'event_title' varchar(50) DEFAULT NULL,
  'date' date DEFAULT NULL,
  'location' varchar(50) DEFAULT NULL,
  'url' varchar(200) DEFAULT NULL,
  PRIMARY KEY ('id'),
  UNIQUE KEY 'event_id' ('event_id','event_title','date','location','url')
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

Теперь вставьте это, чтобы увидеть, что это позволит дублировать строки:

INSERT INTO 'test' ('id', 'event_id', 'event_title', 'date', 'location', 
'url') VALUES (NULL, '1', 'BBQ', '2018-07-27', NULL, NULL);

INSERT INTO 'test' ('id', 'event_id', 'event_title', 'date', 'location', 
'url') VALUES (NULL, '1', 'BBQ', '2018-07-27', NULL, NULL);

Теперь вставьте это и убедитесь, что это не разрешено:

INSERT INTO 'test' ('id', 'event_id', 'event_title', 'date', 'location', 
'url') VALUES (NULL, '1', 'BBQ', '2018-07-28', '', '');

INSERT INTO 'test' ('id', 'event_id', 'event_title', 'date', 'location', 
'url') VALUES (NULL, '1', 'BBQ', '2018-07-28', '', '');

Так что здесь нет правильного или неправильного. Вам решать, что лучше всего работает с вашими бизнес-правилами.

Ответ 7

Я не знаю о производительности. Но с точки зрения качества данных, 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 - ошибка в миллиард долларов.