Где лушче держать поля которые часто меняются? остатки, цены. Отдельно?

Question

[Слава]

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

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

В общем к чему я клоню. Хочу тоже поля, которые меняются часто вынести в отдельную таблицу и при импорте товаров или при ручном редактировании менять только эти таблицы. так ведь будет быстрее работать. чем работать с таблицей в которой 50-60 полей? Или таки нет смысла ?

Почему Ларавел - просто в ларавел есть функционал который удобно подтягивает данные из связанных сущностей через конструкцию with но в итоге получается связанный массив. а иначе придется left join делать а ведь это замедлит работу с товарами. Джойны замедляют скорость работы запроса. Но сильно ли?

Comments

[N]

Джойны замедляют скорость работы запроса. Но сильно ли?

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

Только открою маленький секрет...Ларавел по-умолчанию в with использует where in(...)...
И в некоторых местах лучше использовать как раз "джойны"...

[N]

Чтобы кто-то ответил на Ваш вопрос более точно - предоставьте структуру БД и какие в ней индексы щас расставлены + объём данных и какие данные в какой промежуток времени меняются и в каком кол-ве...

Answer 1

[FanatPHP]

Нет смысла

Comments

[Слава]

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

[FanatPHP]

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

[Слава]

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

[FanatPHP]

ничего не знаю ни про какое логирование.
вопрос был надо ли выносить из таблицы поля отдельно.

[jazzus]

Слава, saveQuietly метод

Answer 2

[Вячеслав Плиско]

В принципе нормальный вариант, на основную сущность может быть навешана куча бизнес логики и индексы, которые апдейтятся. Это упростит вставку, но усложнит обновление и чтение, особенно с фильтрами-сортировками по связанным таблицам .
Главное не забывайте использовать with(), чтобы релейшины грузились одним доп запросом, а не на каждое обращение.

Comments

[Слава]

спасибо! поясните пожалуйста про With() что вы имели ввиду про то чтоб они грузились одним доп зарпосом?
а по другому как это возможно? вы имели ввиду не делать так чтоб в цикле джойнить?

[Вячеслав Плиско]

По умолчанию используется ленивая загрузка и данные подтягивают только при обращении. Если вы выбрали несколько записей, а затем начали обращаться к связанным полям, то каждый раз будут посылаться новые запросы.
Если используете with(), то у вас будет лишь два запроса - сама выборка и ОДИН отдельный, запрос который вытянет все связанные данные. Что гораздо лучше.

[Слава]

Вячеслав Плиско, а разве конструкция

User::select('users.id, users.name, user_proliles.email)
->join(''user_profiles', 'users.id','=', 'user_profiles.id)
->get();

будет делать несколько запосов?

[Вячеслав Плиско]

Давно не писал, но сомневаюсь что в модель можно так джойнить таблицы как в квери билдере.
почему не User::with('user_profiles')?