Laravel поиск модуля?

Question

[Artoym2]

Добрый день, подскажите, хочу найти готовый пакет для создания универсальной структуры для работы с динамическим контентом. Идея в следующем, существует несколько таблиц:
element (хранятся все динамически элементы, выборка происходит по полю type и дополнительным параметрам. Если требуется выбрать из базы данных все новости, делаем запрос select element where type=news)
categories (аналогично с элементами, в базе данных существует поле type, для выборки данных для определенных разделов)

Элементы можно расширить за счет модели Entity–attribute–value в данном случае она позволит создавать свойства у элементов и категорий.

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

Comments

[Vasyl Fomin]

Задавал немного подобный вопрос Оптимальный и быстрый путь создание нового проекта на Laravel? Сейчас делаю свою систему (костили) :)

Answer 1

[Александр Аксентьев]

Будет лагучее говно на выходе(если залить хоть сколько-то приличное количество контента).

EAV хорош для всяких магазинов, делать фасетный поиск и всякое такое.
И то нужна "идеальная" реализация EAV, когда под каждый тип данных своя таблица(integer, string и т.д.).
В Magento как раз такая реализация: devdocs.magento.com/guides/m1x/magefordev/mage-for...

Битрикс использует подобный подход когда всё вот так в кучу, всё типа гибко, но при нагрузке/количестве контента становится понятно за счет чего вся эта гибкость.

Короче зависит от того что за сайт.

Comments

[Artoym2]

Сайты просты как "шаманский бубен", обычно сайта до 50 страниц, порядка 10 разных разделов. Нагрузка минимальная. Понимаю, данных подход используются в системах управления контентом, он вполне, устраивает, для сборки сайта за 1-2 дня данная модель подходит. Все хотят сайты на Laravel

[Александр Аксентьев]

Artoym2, https://octobercms.com/

Answer 2

[sim3x]

Попробуйте

Следующий шаг - хранить запросы к субд в отдельных таблицах данной же БД
После - хранение пхп-кода, который будет работать с запросами из предыдущей, в другой таблице

Если покажется мало - увеличте вложенность

ПС: такое усложнение отладки, тестирования не приносит никаких плюсов.
Ето пусть цмс - которые пытаются делать все и не умеют ничего

Comments

[Златослав Десятников]

Господи, какая наркомания.

[sim3x]

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

[Златослав Десятников]

sim3x, так это не значит, что это нормальная идея. Есть тот же EAV или jsonb-поля в pgsql, которые даже быстрее EAV.

[sim3x]

Златослав Десятников, совершенно верно. Видимо мой сарказм не был замечен

Я к тому что любая смена схемы нормализации БД и попытки сделать унификацию - могут привести к катастрофе

И EAV, json, etc нужно применять очень ограниченно

[Златослав Десятников]

sim3x, да, не уловил сарказм. Тут на Тостере всякое бывает.

[Artoym2]

Хорошо, тебе еженедельно нужно собирать типовые сайты, но клиенты хотят Laravel. Твоя работа превращается в рутину, создание однотипных файлов. Для меня решение кроется в разработке универсального пакета, который можно устанавливать с репозитория. Поделитесь вашим опытом, возможно задачу с создание однотипных сайтов можно решить иначе(кроме использования готовых ЦМС. Я понимаю, мой путь ведет к созданию ЦМС)

[sim3x]

Artoym2, ну вот и делайте бандл, а не говнокод

Нужен клиенту сайт типа Х - сделай репозиторий с максимумом функционала и отрезай лишнее
Не цмс, а именно типовое решение проблемы

Не получится универсального, тем более ваша схема, описанная в вопросе, несет больше проблем чем решает