mini.weblabКот МатроскинЕще раз - я хочу прописать в базе, что нельзя создать продукт без заполненного свойства "цвет".
В традиционной структуре мне для этого нужен один щелчок мышки. Что мне делать в Вашей структуре?
очевидно, не использовать мою структуру :)
Про что я и говорю - а
mini.weblabзадание ограничения NOT NULL в базе
-не поможет никак.

tip78Кот МатроскинЯ про это и говорю - декларативными ограничениями в базе при EAV этого сделать нельзя.
(и даже программными - непросто)
Мы тут все-таки на PHP обсуждаем :)
это не значит, что надо валидацию формы в SQL тащить ))

Какую "валидацию формы"? Это целостность данных , и очень хотелось бы, чтобы ограничения этой целостности лежали бы в одном месте - в СУБД.

tip78пока что только из пальца высосана потребность непременно тащить сырые данные в БД, чтобы там их проверять...
некрасиво прикрытая некой "целостностью данных", которой там в помине ничего не угрожало.

Не, это как-то вяловато :)
Вот когда Вы жгли про преимущества EAV в скорости запросов - вот это был да, трэш и угар.

tip78SERG1257пропущено...
вы хотите сказать констрейнты - зло?
я говорю, что пустышка или нет проверяется на этапе валидации формы
валидация формы это в любом случае процедура обязательная и получается, что своим констрейнтом на NOT NULL вы делаете двойную работу
но это не главное, главное, что в 99% случаев БД вообще не нужно трогать, до тех пор, пока не случится INSERT/UPDATE
(иногда надо конечно проверить, чтобы нужные данные присутствовали в БД, но это другое)
потому что БД это всегда самое узкое место в приложении

Ерунда, конечно.
При вводе номенклатуры товаров (мы, если что, обсуждаем номенклатуру товаров) БД- самое узкое место? Ха-ха три раза.
Сколько в Вашем интернет-магазине описывается новых товаров в сутки ( через PHP-шные формы, да)? хотя бы 100к есть?
Собственно, повторяется история с IBM-овской статьей про наследование - Вы где-то вычитали фразу "БД это всегда самое узкое место в приложении", но даже не попытались задуматься "А к чему она относится? А в каких случаях она применима?"

tip78Кот Матроскинпропущено...

Ерунда, конечно.
При вводе номенклатуры товаров (мы, если что, обсуждаем номенклатуру товаров) БД- самое узкое место? Ха-ха три раза.
Сколько в Вашем интернет-магазине описывается новых товаров в сутки ( через PHP-шные формы, да)? хотя бы 100к есть?
Собственно, повторяется история с IBM-овской статьей про наследование - Вы где-то вычитали фразу "БД это всегда самое узкое место в приложении", но даже не попытались задуматься "А к чему она относится? А в каких случаях она применима?"

а вы за описанием товаров не прячьтесь, это не поможет ))
если вы проверяете NOT NULL через БД, значит так делаете всегда, потому что вам почему-то в голову не приходит, что данные перед походом в БД должны быть проверены.
Что может случиться ДДоС на любой из этих форм и тогда вы увидите не 100к в день, а в секунду, потому что L7 это самая вкусняшка, её все любят.
Что грамотное программирование должно быть везде, и в особенности там, где вам кажется, что "нагрузки нету и всё обойдётся".
"Фразу я вычитал" у хайлоадеров, которые twitter, pinterest, facebook, muut.com (полностью на REDIS кстати) и прочие.
Но ещё мне "повезло" реально влетать на бизнес-приложениях в простои, которые влекут потери моих уже денег и, что куда дороже, репутации.
Мой опыт, сын ошибок трудных, меня научил каждую мелочь учитывать и ожидать всего, поэтому я просчитываю все случаи.
честно я вообще не понимаю, как кому-то с опытом в голову может придти через базу там что-то проверять, кроме самих данных в этой базе
дикость ^^

Во, похоже восприняли мой упрек про "вяловато" и снова развернулись :)
Почти каждая фраза - шедевр (что про "в голову не приходит", что про DDoS на админке магазина и борьбу с ним при помощи отсутствия constraint'ов, что про хайлоадеров ), но больше всего мне понравился довод
Мой опыт, сын ошибок трудных, меня научил каждую мелочь учитывать и ожидать всего, поэтому я просчитываю все случаи в защиту тезиса "Да нафиг проверять корректность данных в БД - и так сойдет" :)