К слову, многие субд умеют и по json полям искать

Решение одной таблицей будет ущербным и выше я писал почему

И кто тебе сказал что по JSON не ищут или что его не индексируют?

это в последних версиях мускуля и постгрес возможно

Решение одной таблицей будет ущербным и выше я писал почему

где написал?

У парня со скрином в бд отсутствует более менее нормальная форма данных. Понятное дело что так делать нехорошо. По крайней мере, в этом контексте. Я бы разносил это по таблицам, а уже внутри, при необходимости, возможно, добавил бы json. Но Николаю походу, плевать, ибо он не читает мои сообщения выше

Я же писал, что никто не читает....

?

У парня со скрином в бд отсутствует более менее нормальная форма данных. Понятное дело что так делать нехорошо. По крайней мере, в этом контексте. Я бы разносил это по таблицам, а уже внутри, при необходимости, возможно, добавил бы json. Но Николаю походу, плевать, ибо он не читает мои сообщения выше

я читал это.. Теперь объясни пожалуйста что для тебя "более-менее" нормальная форма данных? И почему она здесь отсутствует?

Я просто пропустил это сообщение как очередной бред

Потому что данные в той таблице как минимум не в 3-й нормальной форме

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

Потому что данные в той таблице как минимум не в 3-й нормальной форме

а ты знаешь что такое денормализация?

Знаю и она здесь не нужна

Ты понимаешь, зачем нужна нормальная форма? Что здесь она совершенно не нужна? Эти поля используются для чтения а не для выборки

Знаю и она здесь не нужна

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

"поля используются для чтения а не для выборки" - чего??

Не 1000, а максимум 20

"поля используются для чтения а не для выборки" - чего??

это блоки, которые ты выводишь просто

Там не нужно делать выборку по этим полям

И?

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

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

какие 100 полей? Это хранится в 1 поле все будет

Особенно когда выборка будет свыше нескольких лямов строк или когда вдруг нужно будет изменить структуру какогото типа контента.. придётся добавлять в десятках тысячах новое поле со значением null - красота прям

Получается 2 поля key и data

Особенно когда выборка будет свыше нескольких лямов строк или когда вдруг нужно будет изменить структуру какогото типа контента.. придётся добавлять в десятках тысячах новое поле со значением null - красота прям

ты слышал про монго?

Как выше и написали, как там это реализовано?

Особенно когда выборка будет свыше нескольких лямов строк или когда вдруг нужно будет изменить структуру какогото типа контента.. придётся добавлять в десятках тысячах новое поле со значением null - красота прям

это изменяется через код

И как ты будешь гарантировать целостность данных, если у тебя нежёсткая структура? На уровне приложения это рискованно. У меня уже был подобный опыт, не советую

И как ты будешь гарантировать целостность данных, если у тебя нежёсткая структура? На уровне приложения это рискованно. У меня уже был подобный опыт, не советую

можно в таком случае использовать eav

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

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

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

Порой да. Поддрживать одинаковую структуру в jsone удовольствие такое себе

Вообщем ладно пойду работать.. Отдельное спасибо тебе ) Вот так и можно все обсуждать, а не то что этот чувак ничего толком обосновать не может

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

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

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

Окей.. Смотри.. Эти данные довольно часто меняются.. И чтобы изменить какой то блок ты будешь таблицу менять?

Я и не предлагаю новые таблицы. Моя позиция в том, что количество типов контента число фиксированное и потмоу это всё можно описать более жестко

Это зависит от того что именно в блоке я меняю

Я и не предлагаю новые таблицы. Моя позиция в том, что количество типов контента число фиксированное и потмоу это всё можно описать более жестко

так оно в приложении и будет жестко фиксироваться..

Ты создаешь типа блока, вьюху для него и регистрируешь его

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

Можно для твоего решения EAV притянуть, где энтити - типы блоков которые нужно редактировать. Тогда ты сможешь динамически создавать новые типы блоков и определять для них аттрибуты.

Также в этом блоке описываешь типы полей и т.д.. Вот тебе и фиксация. Сразу генерируется модуль в админке под этот блок

Уже говорили про eav)

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

Можно для твоего решения EAV притянуть, где энтити - типы блоков которые нужно редактировать. Тогда ты сможешь динамически создавать новые типы блоков и определять для них аттрибуты.

ну я про него и написал выше

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

хм с чего это?

хм с чего это?

Стого чт мы с тобой обсуждали еав, я тебе описывал варианты реализации, ты зха жсон тогжа топил в реалзиации , я попросил реальнгый юз-кейс привести где от жсон полней в ЕАВ будет профит и то как ты реализацию ЕАВ реализацию видишь с использованием json полей (потому чесно я хуй знает зачем они там нужны, сколько с еав не работал в разных решениях е-комерс, свое писал - нигде нужды в жсон филдах не было), но чет так и не договорили в тот раз.

Стого чт мы с тобой обсуждали еав, я тебе описывал варианты реализации, ты зха жсон тогжа топил в реалзиации , я попросил реальнгый юз-кейс привести где от жсон полней в ЕАВ будет профит и то как ты реализацию ЕАВ реализацию видишь с использованием json полей (потому чесно я хуй знает зачем они там нужны, сколько с еав не работал в разных решениях е-комерс, свое писал - нигде нужды в жсон филдах не было), но чет так и не договорили в тот раз.

аа точно )))

ну с товарами хранение более четкое получается, так что там eav будет лучше, но в данном случае думаю как раз json бы подошел лучше )

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

Из админки никак не возьмешь и не создаешь еще 1 тип

Так как вьюху все равно придется делать

Из админки никак не возьмешь и не создаешь еще 1 тип

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

Что в твоем случае есть "тип" ?

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

ну у каждого типа разная вьюха будет.. Менеджер точно не будет какие то вьюхи создавать )

Что в твоем случае есть "тип" ?

ну тип блока какого то

Секция к примеру имеет тайтл и текст и свой шаблон.. Другая может иметь также подтайтл

То есть надо регистрировать типы и присваивать им вьюхи

В админке выбирать думаю тип и перебилдивать форму под этот тип

ну у каждого типа разная вьюха будет.. Менеджер точно не будет какие то вьюхи создавать )

Если у тебя будет в json все это как то избавит менеджера от необходимости создания вьюх? или от необзодимости того чтобы новая вьюха была кем то создана уже для этих целей?

Регестрировать типы и присваивать им вьюхи можно из админки. EAV как раз и расчитан на создание новых аттрибутов динамически, из админки.

Если у тебя будет в json все это как то избавит менеджера от необходимости создания вьюх? или от необзодимости того чтобы новая вьюха была кем то создана уже для этих целей?

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

Секция к примеру имеет тайтл и текст и свой шаблон.. Другая может иметь также подтайтл

надо разбивать на примитивы и делать так чтоб они могли рендерить сами себя, тогда eav будет работать норм, а сектиции это просто набор примитивов :)

Регестрировать типы и присваивать им вьюхи можно из админки. EAV как раз и расчитан на создание новых аттрибутов динамически, из админки.

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

что титл что под титпл это одн примитив по сути

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

А что мешает в таком случае биндить к новым "блокам" вьюхи

ERROR: S client not available

Вьюха - аттрибут

создаешь новый блок

устанавливаешь ему значение аттрибута view

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

хмм я сейчас подумал а что если сделать динамический view composer

это по проблеме вытягивания блоков по запросу

Просто не надо оверинжиниринга если проблему можно решить каким то более простым путём )

я предлагаю варианты на обсуждение

если тебе не подходит то ок

устанавливаешь ему значение аттрибута view

смотри.. Я хочу в идеале сделать так, чтобы выбираешь такой вьюху.. И сразу форма под нее меняется

То есть это будет не выбор вьюхи а выбор целого блока по ходу

смотри.. Я хочу в идеале сделать так, чтобы выбираешь такой вьюху.. И сразу форма под нее меняется

Меняется где? отображение в админке? или как? не совсем понимаю

Меняется где? отображение в админке? или как? не совсем понимаю

ну да.. Выбрал тип и сразу поля под него подстроились для заполнения

Поэтому я хочу эти типы как то центролизовано подключать

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

ну да.. Выбрал тип и сразу поля под него подстроились для заполнения

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

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

ну я так и хочу сделать.. Просто для этого eav не подойдет

Ну точнее он не нужен так как описание блока будет в коде

интересно а нет для этого готовых решений?

По сути очень нужная штука

ну я так и хочу сделать.. Просто для этого eav не подойдет

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

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

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

а не знаешь какой нибудь пакет для билдинга форм?

а не знаешь какой нибудь пакет для билдинга форм?

https://github.com/barryvdh/laravel-form-bridge https://github.com/kristijanhusak/laravel-form-builder

https://github.com/barryvdh/laravel-form-bridge https://github.com/kristijanhusak/laravel-form-builder

интересно

а сам не юзал?

Здравствуйте!

Подскажите, можно ли произвести поиск в translates?

Есть таблица words и в столбце translates хранятся JSON (string). В модели Word я указал protected $casts = [ 'translates' => 'array', 'examples' => 'array' ];

А почему не разобьешь на две таблицы?

Из-за большого разнообразия