Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Здравствуйте. Сейчас и в ближайшее время, у меня нет возможности протестировать. По сему хочу спросить у вас.
3 модели Item | User | Offer.
Сейчас Item m2m User. А вот тут уже сам вопрос. Как будит правельнее связать User и Offer m2m или one2m, что бы потом сделать такой запрос PHP$item = Item::with('users', 'users.offers')->find($id); распечатать
$item->name
@foreach($item->users as $user)
$user->name
@foreach($user->offers as $offer)
$offer-link
@endforeach
@endforeach
Если все 3 таблицы связаны m2m, не будит ли это большой нагрузкой на бд при больших обьемах данных?
И вообще, можно ли получить offer если она связана one2m с user, а user связана с item m2m? Потому что когда я последний раз пытался так делать,в relations у меня был null
Не в сети
Мастер
Писарь
"Посему" пишется слитно.
"будЕт" пишется через Е, а то будильник.
"правИльно" пишется через И, а то весло.
Может рано программить? В коде подобные ошибки непростительны!
>Если все 3 таблицы связаны m2m
Зависит от задачи, нагрузки, архитектуры и объёма данных. При 100 000 записей в каждой таблице - встанет.
Есть резон дёргать связи БЕЗ ->with(), но дёргать связи там и где нужно.
Потому что 100500 простых Select * FROM table WHERE id=? быстрее/надёжнее, если ты склеишь всё одним-тремя JOIN, который может вывалиться в ошибку по нехватки памяти процессу PHP, бд-то всё похрен, она отдась всё.
Изменено hzone (20.11.2016 21:52:02)
Не в сети
"Посему" пишется слитно.
"будЕт" пишется через Е, а то будильник.
"правИльно" пишется через И, а то весло.Может рано программить? В коде подобные ошибки непростительны!
>Если все 3 таблицы связаны m2m
Зависит от задачи, нагрузки, архитектуры и объёма данных. При 100 000 записей в каждой таблице - встанет.
Есть резон дёргать связи БЕЗ ->with(), но дёргать связи там и где нужно.
Потому что 100500 простых Select * FROM table WHERE id=? быстрее/надёжнее, если ты склеишь всё одним-тремя JOIN, который может вывалиться в ошибку по нехватки памяти процессу PHP, бд-то всё похрен, она отдась всё.
Ну да, я делаю ошибки в тексте. Но ведь тут не урок Русского языка, и мы не пишем сочинение.
А за ответ спасибо!
UPD: В коде не пишу на Русском
Изменено TrueKanonir (20.11.2016 22:16:21)
Не в сети
Не стал создавать новую тему.
Хотел спросить. На сайте в сайдбаре выводятся все категории с количеством постов на всех страницах сайта. При большом количестве постов, нагрузка на бд будит рости и рости. Думаю добавить колонку posts_count в таблицу с категориями. И тут встал вопрос. Как правильно это сделать? Первое что приходит на ум,это model events. Каждый раз при добавлении нового поста, считать количество постов у категории и заносить результат в posts_count. Или может есть более лаконичный и правильный способ?
Не в сети
}%Не стал создавать новую тему.
Хотел спросить. На сайте в сайдбаре выводятся все категории с количеством постов на всех страницах сайта. При большом количестве постов, нагрузка на бд будит рости и рости. Думаю добавить колонку posts_count в таблицу с категориями. И тут встал вопрос. Как правильно это сделать? Первое что приходит на ум,это model events. Каждый раз при добавлении нового поста, считать количество постов у категории и заносить результат в posts_count. Или может есть более лаконичный и правильный способ?
Ну так как мне поступить в данном случае разумнее? Хотелось бы услышать ваше мнение.
Не в сети
Мастер 
Ну так как мне поступить в данном случае разумнее? Хотелось бы услышать ваше мнение.
поле со счётчиком постов и есть разумнее всего сделать. самому писать обработчики не нужно – всё есть уже готовое
Не в сети
МастерПисарь
Найди в этом разделе тему с названием [РЕШЕНИЕ].
Поможет.
Вообще прими за привычку сначала искать по форуму.
А то испорченный телефон получается.
Не в сети
TrueKanonir пишет:Ну так как мне поступить в данном случае разумнее? Хотелось бы услышать ваше мнение.
поле со счётчиком постов и есть разумнее всего сделать. самому писать обработчики не нужно – всё есть уже готовое
Не знал о таком пакете. Благодарю! То что нужно.
Изменено TrueKanonir (23.12.2016 12:44:14)
Не в сети
Найди в этом разделе тему с названием [РЕШЕНИЕ].
Поможет.
Вообще прими за привычку сначала искать по форуму.
А то испорченный телефон получается.
Я искал и по форуму, и гуглил. И везде предлагали использовать триггеры или model events. По этому и решил спросить тут.
Не в сети
Мастер не, триггеры это перебор. рассматривай поле счётчика как вариант кэша, просто значение хранится сразу в таблице.
подскажу – счётчики комментов, постов и просто просмотров можно хранить прямо в самом кэше, особенно если кэш сделан на редисе и его состояние сохраняется при рестарте системы. всё-таки изменение счётчика – это уже UPDATE, а все операции меняющие данные в БД не самые быстрые (особенно если поле проиндексировано). в то же время редису поменять значение счётчика – это просто изменить несколько байтов в памяти. для высоконагруженных проектов есть смысл в таких оптимизациях.
что касается kirkbushell/eloquence то он на событиях моделей и работает – поэтому там предусмотрены методы принудительного пересчёта, ведь если изменения в таблицы вносятся каким-то другим способом кроме как через модели (например через построитель запросов) – при этом счётчики не будут изменяться и их значения будут становиться неактуальны, имей в виду.
Не в сети
МастерПисарь
Model events или триггеры требуется сопровождать.
Если готов их сопровождать - молодец, а если "что есть `сопровождать`?", то - "не рано ли"?
Не в сети
не, триггеры это перебор. рассматривай поле счётчика как вариант кэша, просто значение хранится сразу в таблице.
подскажу – счётчики комментов, постов и просто просмотров можно хранить прямо в самом кэше, особенно если кэш сделан на редисе и его состояние сохраняется при рестарте системы. всё-таки изменение счётчика – это уже UPDATE, а все операции меняющие данные в БД не самые быстрые (особенно если поле проиндексировано). в то же время редису поменять значение счётчика – это просто изменить несколько байтов в памяти. для высоконагруженных проектов есть смысл в таких оптимизациях.
что касается kirkbushell/eloquence то он на событиях моделей и работает – поэтому там предусмотрены методы принудительного пересчёта, ведь если изменения в таблицы вносятся каким-то другим способом кроме как через модели (например через построитель запросов) – при этом счётчики не будут изменяться и их значения будут становиться неактуальны, имей в виду.
Спасибо за разъяснение. Пока обойдусь пакетом, ибо проект не особо и нагруженный.
Не в сети
Model events или триггеры требуется сопровождать.
Если готов их сопровождать - молодец, а если "что есть `сопровождать`?", то - "не рано ли"?
Рано никогда не бывает. Бывает только поздно. И да, готов сопровождать если этого требует задача.
Не в сети
Страницы 1
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)