Null из PHP в SQL запрос - за и против.

[Вурдалак]

Фанат, unset нельзя. Мы хотим присвоить NULL, а не игнорировать вообще. В чем проблема при === null вставлять в запрос NULL я не понимаю.

 

[Фанат]

Фанат, unset нельзя.

Почему нельзя?
приведи пример, где это не работает?

В чем проблема при === null вставлять

Лишний код

 

[Вурдалак]

Фанат, INTEGER NULL DEFAULT 42

 

[Фанат]

вот вы затейники. я бы за такое просто убивал и ставил к стенке.

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

if ($var === NULL) {
    $sqlpart = "field = NULL";
} else {
    $sqlpart = $db->parse("field = ?s",$var);
}

 

[grigori]

мешала ли замена NULL в РНР на пустую строку в запросе?

да, когда в таблице у поля тип int и по нему FK на другую таблицу, надо указывать в запросе именно NULL, иначе

/* SQL Error (1452): Cannot add or update a child row: a foreign key constraint fails (`test`.`t2`, CONSTRAINT `FK_t2_t` FOREIGN KEY (`f2`) REFERENCES `t` (`a`)) */

 

[~WR~]

Миллион примеров. Особенно в апдейтах.

Снимаем флаг удаления с пользователя:

$upd = array('deleted_date' => null);
$DB->update('users', $upd, $user_id);

Null это null, default это default. Если в SQL это разные понятия, то почему класс БД должен считать иначе?

 

[Вурдалак]

О, мы теперь еще и извращенцы и кода нам почему-то надо больше писать. OK.

 

[Фанат]

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

Хотим вставить нулл - делаем это явно руками.

 

[grigori]

~WR~ в твоем случае алгоритм неправильный: флаг удаления должен быть отдельным полем типа bool/tinyint, после снятия поле deleted_date надо игнорировать,
использование специального значения NULL для обозначения состояния неуместно,
основной аргумент: NULL - отсутствие значения, а не значение состояния

 

[~WR~]

Убивать и ставить к стенке тоже не за что.

Возможно, люди просто слишком привыкли смотреть на мир через призму MySQL.
Точно не знаю, как сейчас это работает, но в прошлом много раз читал, что Nullable колонки добавляют лишний overhead на хранение данных.

Зато, например, в том же PG картина совершенно обратная. Все поля со значением null физически хранятся в виде компактной битовой маски. Это позволяет очень быстро фильтровать по условию IS NULL, IS NOT NULL.
Также, например, можно сделать моментальный ALTER TABLE .. ADD COLUMN, если новая колонка по умолчанию Null и влазит в размер старой маски. В этом случае достаточно поменять мета-информацию и всё.

Потом, уникальные индексы. Они позволяют записывать сколько угодно рядов с Null, но только один ряд с другими значениями.
Периодически пользуюсь этой особенностью и никакого криминала не вижу. Это базовые SQL-концепции, и много других вещей отлично живут on top of it.

 

[grigori]

Хотим вставить нулл - делаем это явно руками.

Show me the code (C)
чем выражение SQLExpression('Null') лучше, чем прямой маппинг значения NULL в поле класса, который создан для маппинга?

 

[Фанат]

Show me the code (C)
чем выражение SQLExpression('Null') лучше, чем прямой маппинг значения NULL в поле класса, который создан для маппинга?

1. Распространить поведение на все плейсхолдеры нельзя - обычный скалярный плейсхолдер при таком поведении вызовет ошибку в запросе SELECT со сравнением.
2. Делать только для полейсхолдера на вставку - это исключение, а исключений надо стараться избегать.

 

[grigori]

я понял, у меня 80% запросов делается через ORM-классы, который реализуют Active Record,
с plain SQL сложнее