Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > MySQL > NOT NULL поля хранят пустые строки

Автор: azesmcar 27.11.2009, 08:34

Добрый день, Столкнулся с такой проблемой, MySQL позволяет записывать пустые строки в NOT NULL поля. Код mysql> CREATE DATABASE mydb; Query OK, 1 row affected (0.00 sec) mysql> use mydb; Database changed mysql> CREATE TABLE mytable (field1 VARCHAR(10) NOT NULL, field2 VARCHAR(10) NOT NULL); Query OK, 0 rows affected (0.02 sec) mysql> INSERT INTO mytable (field1, field2) VALUES ('',''); Query OK, 1 row affected (0.00 sec) mysql> Немного поискал в гугле, нашел вот это http://bugs.mysql.com/bug.php?id=30958 но здесь видно что это описание ошибки не в MySQL а в Connector/ODBC, хотя проблема в точности повторяет мою а для связи я использую Native MySQL client. Версия MySQL 5.0. Кто нибудь сталкивался?

Автор: Akina 27.11.2009, 08:42

Цитата(azesmcar @  27.11.2009,  09:34 ) Столкнулся с такой проблемой, MySQL позволяет записывать пустые строки в NOT NULL поля. Правильно позволяет. Пустая строка - это строка. Пусть и нулевой длины. Это тебе не Оракл (где, кстати, из-за этого возникают определённые проблемы).

Автор: azesmcar 27.11.2009, 09:24

Цитата(Akina @  27.11.2009,  08:42 ) Правильно позволяет. Пустая строка - это строка. Пусть и нулевой длины. Это тебе не Оракл (где, кстати, из-за этого возникают определённые проблемы). Да я как раз по ораклу смотрю, привык. Проблем у меня с этим пока не возникало, а что с этим маразмом делать? Мне нужна валидация not empty  какая нафиг разница null или пустая строка? Валидации фактически нет. Для текста что NULL что пустая строка. Поле Login можно запросто пустым оставить, от того что там не NULL а пустая строка мне не легче.

Автор: DimW 27.11.2009, 09:28

Цитата(Akina @  27.11.2009,  08:42 ) где, кстати, из-за этого возникают определённые проблемы проблемы возникают у разработчиков которые приходят в оракл их других СУБД, впрочим как и на оборот  вот к примеру стоит задача получить данные где поле field равно 'value' или пустое, тогда запрос должен выглядеть так что ли? Код select * from table  where field = 'value'     or field is null     or field = '' т.е. для идентификации пустого значения потребуется писать два условия вместо одного? коряво как то... Добавлено @ 09:31 Цитата(azesmcar @  27.11.2009,  09:24 )  а что с этим маразмом делать?  повесить чек констрайнт field <> '' or length(field) <> 0 полагаю.

Автор: Akina 27.11.2009, 09:34

Цитата(azesmcar @  27.11.2009,  10:24 ) нафиг разница null или пустая строка? Разница? огромная. Какой тип имеет значение "Null"? а хрен его знает... Какой тип имеет значение "пустая строка"? строка - без вариантов... А ты говоришь - какая нафиг разница...

Автор: azesmcar 27.11.2009, 09:38

Цитата(DimW @  27.11.2009,  09:28 ) проблемы возникают у разработчиков которые приходят в оракл их других СУБД, впрочим как и на оборот     Цитата(DimW @  27.11.2009,  09:28 ) повесить чек констрайнт field <> '' or length(field) <> 0 полагаю.  Цитата(Manual) The CHECK clause is parsed but ignored by all storage engines http://dev.mysql.com/doc/refman/5.1/en/create-table.html Добавлено @ 09:39 Цитата(Akina @  27.11.2009,  09:34 ) Разница? огромная. Какой тип имеет значение "Null"? а хрен его знает... Какой тип имеет значение "пустая строка"? строка - без вариантов... А ты говоришь - какая нафиг разница...  какая МНЕ разница? Поле логин то все равно пустое  не знаю, по мне так в Оракл это намного лучше продумано.

Автор: Akina 27.11.2009, 09:39

Цитата(DimW @  27.11.2009,  10:28 ) т.е. для идентификации пустого значения потребуется писать два условия вместо одного? Нет, одно. И ещё одно - для идентификации отсутствия значения. А если надо проверить и то, и другое - то две проверки. Либо использование функции, проверяющей значение на null и при соответствии заменяющее на нечто требуемое. Например  Код where NZ(field, '') <> '' проверит на пустую строку и null одновременно (диалектозависимо).

Автор: DimW 27.11.2009, 09:42

Цитата(Akina @  27.11.2009,  09:34 ) Какой тип имеет значение "пустая строка"? строка - без вариантов... Akina, я думаю у azesmcar, как и у меня просто возникают сомнения в полезности и удобстве этой разницы.

Автор: Akina 27.11.2009, 09:42

Цитата(azesmcar @  27.11.2009,  10:38 ) какая МНЕ разница? Поле логин то все равно пустое А это ТВОЯ ошибка. Кто позволил не заполнять это поле при создании записи или изменять его в созданной ранее записи? Программер. Который обязан был написАть код проверки корректности заносимых в таблицу данных. Но не сделал этого.

Автор: azesmcar 27.11.2009, 09:43

Цитата(Akina @  27.11.2009,  09:42 ) А это ТВОЯ ошибка. Кто позволил не заполнять это поле при создании записи или изменять его в созданной ранее записи? Программер. Который обязан был написАть код проверки корректности заносимых в таблицу данных. Но не сделал этого.  Так я и пытаюсь эту проверку написать  Цитата(DimW @  27.11.2009,  09:42 ) Akina, я думаю у azesmcar, как и у меня просто возникают сомнения в полезности и удобстве этой разницы.     но вернемся к теме, что делать то? CHECK не поддерживается, NOT NULL не работает   не триггеры же писать в конце концов

Автор: Akina 27.11.2009, 09:47

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

Автор: DimW 27.11.2009, 09:57

Цитата(Akina @  27.11.2009,  09:47 ) Делать триггер на вставку  я вот не пойму: есть две таблицы, одна родительская одна подчиненная, натягиваем на одну первичный ключ который not null вставляем в туда "пустую строку", натягиваем связь от подчененной к родительской и что получается - я могу в подчиненную вставить "пустую строку". нихера себе констрейнтик!

Автор: azesmcar 27.11.2009, 09:58

Цитата(Akina @  27.11.2009,  09:47 ) И отогнать программную часть от таблиц (ибо нефиг) - создавай необходимые для работы вьюхи и работай с данными через них.  До этого еще добраться нужно. Цитата(Akina @  27.11.2009,  09:47 ) Делать триггер на вставку и изменение, и проверять, что в таблицу не суют ни null, ни пустую строку. А вот эта идея мне не очень нравиться, ради валидации пустой строки триггер делать, но как я понял по другому никак..Ладно, спасибо. Тема закрыта.

Автор: Akina 27.11.2009, 10:00

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

Автор: DimW 27.11.2009, 10:05

Цитата(Akina @  27.11.2009,  10:00 ) Всё законно, соответствие есть. ага и "пустая строка" является идентификатором записи  . правильно?

Автор: Akina 27.11.2009, 10:10

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

Автор: DimW 27.11.2009, 10:18

Цитата(Akina @  27.11.2009,  10:10 ) А почему нет? чем она хуже любой другой строки?  Akina, ты знаешь, наверное это из разряда - когда считали что земля плоская а потом выяснелось что нет, и в голове не умещается как с этим теперь жить...

Автор: Akina 27.11.2009, 10:36

Ну... в общем да.  Цитата(azesmcar @  27.11.2009,  10:58 )  эта идея мне не очень нравиться, ради валидации пустой строки триггер делать, но как я понял по другому никак Да пожалуйста! вынеси эту логику на клиента, если тебе не нравится триггер. Это, конечно, идеологически плохо, но вполне работоспособно.

Автор: azesmcar 27.11.2009, 10:39

Цитата(Akina @  27.11.2009,  10:36 ) Да пожалуйста! вынеси эту логику на клиента, если тебе не нравится триггер. Это, конечно, идеологически плохо, но вполне работоспособно.  Вынес, думаю над триггерами.

Автор: Zloxa 27.11.2009, 11:33

Милый вышел холиварчик  В бытность, когда я писал для MS, я  находил вполне естественным и понятным, что null и '' cуть разные вещи. И тому я находил применение. Когда я переполз на ораклю, был несколько шокирован положением дел в оном. Однако теперь привык. Случай, когда имеет смысл разделять понятия null и '' теперь не могу придумать. Однако то, что length('') возвращает Null, instr('','A') возвращает null - и ныне нахожу нелогичным ну не маразм ли?: Код SQL> select s,length(replace(s,'A')) from (   2    select 'ABAB' s  from dual   3    union all select 'AAA' from dual   4    union all select 'BBB' from dual   5  )   6  ;   S    LENGTH(REPLACE(S,'A')) ---- ---------------------- ABAB                      2 AAA   BBB                       3

Автор: Akina 27.11.2009, 11:55

Цитата(Zloxa @  27.11.2009,  12:33 ) Случай, когда имеет смысл разделять понятия null и '' теперь не могу придумать. Если значение поля при создании записи не заполняется (поле отсутствуе в insert into), а впоследствии может заполняться и корректироваться (в т.ч. очищаться, но не за-null-яться - поле обязательно присутствует в update table) - наличие null свидетельствует о том, что запись с момента заведения больше не обрабатывалась. Цитата(Zloxa @  27.11.2009,  12:33 ) ну не маразм ли?: MySQL более логичен... Код mysql> use test Database changed mysql> create table test (txt text); Query OK, 0 rows affected (0.16 sec) mysql> insert into test (txt) values ('ABAB'),('AAAA'),('BBBB'),(null); Query OK, 4 rows affected (0.02 sec) Records: 4  Duplicates: 0  Warnings: 0 mysql> select txt,replace(txt,'A',''),length(replace(txt,'A','')) from test; +------+---------------------+-----------------------------+ | txt  | replace(txt,'A','') | length(replace(txt,'A','')) | +------+---------------------+-----------------------------+ | ABAB | BB                  |                           2 | | AAAA |                     |                           0 | | BBBB | BBBB                |                           4 | | NULL | NULL                |                        NULL | +------+---------------------+-----------------------------+ 4 rows in set (0.00 sec) mysql>

Автор: Zloxa 27.11.2009, 12:12

Цитата(Akina @  27.11.2009,  11:55 )  наличие null свидетельствует о том ) Не находишь, что это какойто натуралистический подход  Из разряда того, что по тому, как растет мох - определить где север. Это как бы изначально предполагает что ты не знаешь где север, а следовательно не владеешь ситуацией. В СУБД ты являешься творцом мира и создавать мох только для того чтобы потом самому же определять по его росту где север - наверное было бы не логично. Если нам необходимо знать инфомрацию о том апдейтилась ли запись после инсерта - от чего бы не хранить дату создания и дату модификации? Цитата(Akina @  27.11.2009,  11:55 ) MySQL более логичен... И я ж о том же  Так маразм кажется еще чуть более крепким: Код SQL> select s,instr(replace(s,'A'),'A') from (   2    select 'ABAB' s  from dual   3    union all select 'AAA' from dual   4    union all select 'BBB' from dual   5  )   6  ;   S    INSTR(REPLACE(S,'A'),'A') ---- ------------------------- ABAB                         0 AAA   BBB                          0

Автор: Akina 27.11.2009, 12:36

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

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)