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

И все можно спроектировать нормально

А для остального noSql

так а чего ради мутить nosql, если есть возможность не плодить движки?

С этим надо будет как-то работать в будущем, все равно прийдётся структурировать

Если бы так было. никто б не делал такой тип поля в базах

КОроче, я так понял, нужно переделать это все. Мда, не очень то обратносовместимо

так а чего ради мутить nosql, если есть возможность не плодить движки?

Это частный случай, как часто вам встречаются не структурированные данные?

Это частный случай, как часто вам встречаются не структурированные данные?

прям щас с ними сижу лицом к лицу. есть построитель отчетов, в нем несколько типов отображения данных, у каждого типа есть json-конфижка для всяких цветов, шрифтов, серий

вот сменю я компонент отображения или добавлю новый тип дисплея, мне надо перефигачивать все свои таблицы, получается

СТРУКТУРИРОВАННЫЕ

кстати, была такая цмс котонти, которая реализовала набор кастомных полей для страничек

и реализовала их, тупо добавляя новые колонки в таблицу страничек

Ну вот конфижки и есть noSql

и реализовала их, тупо добавляя новые колонки в таблицу страничек

взрыв шаблона ?

ну так понятно, но если есть возможность хранить их в json-поле, почему ею не воспользоваться?

по моему это сложнее (

взрыв шаблона ?

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

ну так понятно, но если есть возможность хранить их в json-поле, почему ею не воспользоваться?

Конфиги не структурированные

так вы предлагаете нормально проектировать, не? чтобы все было структурированное

И это ок

Странно откуда такой интерес) это не так часто встречается и вроде попаболью никогда не отзывалось

так вы предлагаете нормально проектировать, не? чтобы все было структурированное

так есть же динамические поля ) и кеширование

так есть же динамические поля ) и кеширование

кэширование-то здесь каким боком?))

ну шоб не драло мускуль каждый раз ) типа деревянное поле

И все таки, кто-нибудь может объяснить почему Json в структурированных данных? И какой он даст профит по сравнению с обычным отношением и выделенной таблицей?

скорость

['label' => 'sign in', 'visible' => Yii::$app->user->isGuest]

Спасибо!

скорость

В - поддерживаемости?

В - поддерживаемости?

в выборке

в выборке

В минус поддерживаемости кода

Вы видимо не работали с проектами в которых половина всего не регулярках которые в базе хранятся ?

может, оно и к лучшему

Вы видимо не работали с проектами в которых половина всего не регулярках которые в базе хранятся ?

тебе просто sql запросы в js не встречались видимо ?

тебе просто sql запросы в js не встречались видимо ?

Не, это было но в десктопе ?

json ок для eav

а то заебался бы для каждой опции свои поля лупить

а то заебался бы для каждой опции свои поля лупить

А проблемы с поиском не смущают? )

тебе просто sql запросы в js не встречались видимо ?

Отличная идея для нового фреймворка

А проблемы с поиском не смущают? )

По Json можно искать в новых версиях mysql

По Json можно искать в новых версиях mysql

Я не говорю что json плох. У всего свое предназначение. Для eav я его не вижу в реляционной бд. Может ты меня переубедишь?

А чем плохо? Я вот думаю вместо еав делать как раз JSON поля. ПО ним же поиск норм, выборка, и т. д. А ЕАВ кажется какой-то уж очень громоздкой

КОроче, я так понял, нужно переделать это все. Мда, не очень то обратносовместимо

Они не специально, как оказалось

Я не говорю что json плох. У всего свое предназначение. Для eav я его не вижу в реляционной бд. Может ты меня переубедишь?

предложи вариант для решения задачи с опциями товара, когда одна опция - текст, вторая - число, третья - флоат и т.д.

как по мне - сделал тип поля value json и погнал

и шаред хостинг найти со свежей mysql

Проблемы негров шерифа не волнуют

предложи вариант для решения задачи с опциями товара, когда одна опция - текст, вторая - число, третья - флоат и т.д.

Да это все давно в oc сделано)

В чем?

OpenCart

А как там?

предложи вариант для решения задачи с опциями товара, когда одна опция - текст, вторая - число, третья - флоат и т.д.

как такие поля потом сравнение товару делать?

или фильтр

Вообще для товара, если его дохрена делается индексация в elasticsearch и там уже гонишь куда хочешь

как такие поля потом сравнение товару делать?

Я сделаю и потом расскажу как

тоже аналогичная задачка стоит, сделать сраные характеристики товаров чтобы были разные где то бул где то селективный список, но чот это тяжеловато осмыслить как все устроить ) хоть бы на ютубчике кто нить запилил ))

Оооо

Ну так как, по json полю же выборка работает

OpenCart

по моему в нем вообще повеситься можно )

? или он почти как йии ?

Не, совсем не такой

по моему в нем вообще повеситься можно )

Ну он вобще вроде ниче такой, но обновлений нормальных нету

Знакомому пробовал обновить на новую версию - завесится можно

http://shot.hsdn.org/K6mrWVjF

можно ли в этом случае сделать фильтрацию?

?

http://www.yiiframework.com/doc-2.0/yii-base-model.html#addError()-detail

ERROR: S client not available

Гуглится за пару секунд

http://shot.hsdn.org/K6mrWVjF

А че нельзя? Добавляются условия по JSON

http://shot.hsdn.org/K6mrWVjF

Если делал основу в gii, то в модели поиска сделать поле для этого, а его уже разбирать в modelSearch::search(), т.е. добавлять несколько условий в where по разным физическим полям модели

А че нельзя? Добавляются условия по JSON

Ок. Мне просто уверенности не хватало

Но я еще не пробовал, если че)

Пишут, что медленнее будет

Реально, хотелось бы вместо EAV использовать JSON поля

http://www.yiiframework.com/doc-2.0/yii-base-model.html#addError()-detail

а как добавлять если не известен атрибут

а как добавлять если не известен атрибут

Ошибки валидации добавляются к атрибутам. Если аттрибут неизвестен - это не имеет смысла

ну смотри, мне нужно проверить что нет дубликатов в бд, для этого мне достаточно сделать try catch (IntegrityException) и в случае catch выдать ошибку. но писать это в validate() нельзя ведь тогда при смене пароля, например, оно будет выдавать эту ошибку

Чтобы не было дубликатов, делай в БД уникальное поле, и валидатор unique, тогда точно не будет. Зачем отдельно проверять?

ааааа

есть валидатор unique

А у тебя какое-то извращение с отловлей ексепшнов)

тогда все намного легче

Есть. конечно)

В любом случае, проверяется по какому-нижуть полю

В любом случае, проверяется по какому-нижуть полю

[['username', 'email'], 'unique'], я так написал и когда нажал сабмит такая ошибка

я так понимаю нужен метод find

Потому-что модель формы, это просто модель, а не ActiveRecord, соответственно, она не может валидовать unique, так как нужно делать запрос к базе. Для этого есть свойства в валидаторе, где нужно прописать модель, которая уже работает с базой (User, очевидно)

https://yiiframework.com.ua/ru/doc/guide/2/tutorial-core-validators/#unique

аааа ну тогда активформ

Тут есть

я понял

я в юзер пропишу этот рул

аааа ну тогда активформ

Это вообще виждет

Нет. не понял

но тогда ошибка про поле в вью

В Юзер нужно, да. он отвечает конкретно за работу с базой

не будте асоциирована с полем