А почему нет? чем она хуже любой другой строки?

Akina, ты знаешь, наверное это из разряда - когда считали что земля плоская а потом выяснелось что нет, и в голове не умещается как с этим теперь жить...   

Ну... в общем да. 

Да пожалуйста! вынеси эту логику на клиента, если тебе не нравится триггер. Это, конечно, идеологически плохо, но вполне работоспособно.

Вынес, думаю над триггерами.

Это сообщение отредактировал(а) azesmcar - 27.11.2009, 10:40

Милый вышел холиварчик 

В бытность, когда я писал для MS, я  находил вполне естественным и понятным, что null и '' cуть разные вещи. И тому я находил применение.
Когда я переполз на ораклю, был несколько шокирован положением дел в оном. Однако теперь привык. Случай, когда имеет смысл разделять понятия null и '' теперь не могу придумать. Однако то, что length('') возвращает Null, instr('','A') возвращает null - и ныне нахожу нелогичным

ну не маразм ли?:

Если значение поля при создании записи не заполняется (поле отсутствуе в insert into), а впоследствии может заполняться и корректироваться (в т.ч. очищаться, но не за-null-яться - поле обязательно присутствует в update table) - наличие null свидетельствует о том, что запись с момента заведения больше не обрабатывалась.


MySQL более логичен...


Это сообщение отредактировал(а) Akina - 27.11.2009, 12:04

)
Не находишь, что это какойто натуралистический подход  Из разряда того, что по тому, как растет мох - определить где север. Это как бы изначально предполагает что ты не знаешь где север, а следовательно не владеешь ситуацией.

В СУБД ты являешься творцом мира и создавать мох только для того чтобы потом самому же определять по его росту где север - наверное было бы не логично.

Если нам необходимо знать инфомрацию о том апдейтилась ли запись после инсерта - от чего бы не хранить дату создания и дату модификации?


И я ж о том же 
Так маразм кажется еще чуть более крепким:

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