Добрый день,

Столкнулся с такой проблемой, MySQL позволяет записывать пустые строки в NOT NULL поля.

Немного поискал в гугле, нашел вот это
http://bugs.mysql.com/bug.php?id=30958
но здесь видно что это описание ошибки не в MySQL а в Connector/ODBC, хотя проблема в точности повторяет мою а для связи я использую Native MySQL client. Версия MySQL 5.0. Кто нибудь сталкивался?

Правильно позволяет. Пустая строка - это строка. Пусть и нулевой длины. Это тебе не Оракл (где, кстати, из-за этого возникают определённые проблемы).

Да я как раз по ораклу смотрю, привык. Проблем у меня с этим пока не возникало, а что с этим маразмом делать? Мне нужна валидация not empty  какая нафиг разница null или пустая строка? Валидации фактически нет. Для текста что NULL что пустая строка. Поле Login можно запросто пустым оставить, от того что там не NULL а пустая строка мне не легче.

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

проблемы возникают у разработчиков которые приходят в оракл их других СУБД, впрочим как и на оборот 

вот к примеру стоит задача получить данные где поле field равно 'value' или пустое, тогда запрос должен выглядеть так что ли?


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

Добавлено @ 09:31

повесить чек констрайнт field <> '' or length(field) <> 0 полагаю. 

Это сообщение отредактировал(а) DimW - 27.11.2009, 09:31

Разница? огромная.
Какой тип имеет значение "Null"? а хрен его знает...
Какой тип имеет значение "пустая строка"? строка - без вариантов...
А ты говоришь - какая нафиг разница...

  



http://dev.mysql.com/doc/refman/5.1/en/create-table.html

Добавлено @ 09:39

какая МНЕ разница? Поле логин то все равно пустое 

не знаю, по мне так в Оракл это намного лучше продумано.

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

Нет, одно.
И ещё одно - для идентификации отсутствия значения. А если надо проверить и то, и другое - то две проверки. Либо использование функции, проверяющей значение на null и при соответствии заменяющее на нечто требуемое.
Например проверит на пустую строку и null одновременно (диалектозависимо).

Akina, я думаю у azesmcar, как и у меня просто возникают сомнения в полезности и удобстве этой разницы.

А это ТВОЯ ошибка. Кто позволил не заполнять это поле при создании записи или изменять его в созданной ранее записи? Программер. Который обязан был написАть код проверки корректности заносимых в таблицу данных. Но не сделал этого.

Так я и пытаюсь эту проверку написать 


  

но вернемся к теме, что делать то?
CHECK не поддерживается, NOT NULL не работает  
не триггеры же писать в конце концов

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

Делать триггер на вставку и изменение, и проверять, что в таблицу не суют ни null, ни пустую строку.
И отогнать программную часть от таблиц (ибо нефиг) - создавай необходимые для работы вьюхи и работай с данными через них.

я вот не пойму:
есть две таблицы, одна родительская одна подчиненная, натягиваем на одну первичный ключ который not null вставляем в туда "пустую строку", натягиваем связь от подчененной к родительской и что получается - я могу в подчиненную вставить "пустую строку". нихера себе констрейнтик!   

  

До этого еще добраться нужно.


А вот эта идея мне не очень нравиться, ради валидации пустой строки триггер делать, но как я понял по другому никак..Ладно, спасибо.

Тема закрыта.

Пустую строку вставить сможешь. А null не сможешь. И не понимаю, что тебе не нравится. Всё законно, соответствие есть.

ага и "пустая строка" является идентификатором записи  . правильно?

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

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 как раз в поле клалась пустая строка, и оператор, осуществлявший обработку, не получал ранее просмотренные записи на повторный просмотр.