и что?

дичь

зачем запросы плодить

>и у каждого айтема будет запрос к базе? через with c замыканием так уже не будет

все здравствуйте

если делать $item->likes() то будет

а если $item->likes то не будет

и для count'а по отношению вроде был какой-то нативный метод

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

Привет всем, кто-нибудь знает как правильно реализовать модель которая размазана по нескольким таблицам, аля topics, topicsArchive, topicsArchive2016 и т.д. ?

Посоветуйте пжл, по моему вопросу

$item->likes->pluck('id')->contains(auth()->id())

if

Посоветуйте пжл, по моему вопросу

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

Привет всем, кто-нибудь знает как правильно реализовать модель которая размазана по нескольким таблицам, аля topics, topicsArchive, topicsArchive2016 и т.д. ?

Сделать одну точку входа - главную модель с базовыми данными типа айдишника, названия и т.д.. И связанные с ней через нужные типы связей если требуются. Как например $user->profile, где в юзере - базовое для авторизации, а в профиле всякое подробное.

Такая архитектура уже задана. Не с нуля пишу. К тому же это нормальная практика на highload проекте

Сделать одну точку входа - главную модель с базовыми данными типа айдишника, названия и т.д.. И связанные с ней через нужные типы связей если требуются. Как например $user->profile, где в юзере - базовое для авторизации, а в профиле всякое подробное.

В этих таблицах не отношения, это типа партиционирование

highload на ларвеле?

лол

highload на ларвеле?

lumen если быть точнее

highload на php? :)

люмен труп

Привет всем, кто-нибудь знает как правильно реализовать модель которая размазана по нескольким таблицам, аля topics, topicsArchive, topicsArchive2016 и т.д. ?

morph

highload на php? :)

давайте без холиваров

но хайлод на люмене/лара - смешно

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

в таблице topics - topicable_id и topicable

но хайлод на люмене/лара - смешно

только вчера у знатоков спрашивал

вполне реально

хоть на чем хайлоад пилить

Привет всем, кто-нибудь знает как правильно реализовать модель которая размазана по нескольким таблицам, аля topics, topicsArchive, topicsArchive2016 и т.д. ?

Elequnt это active рекорд, значит 1 модель - 1 запись в таблице, тут нужно отношениями

а в чем проблема laravel и хайлод? оверхеды минимальные

но хайлод на люмене/лара - смешно

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

не знаю

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

в чем проблема монолита

лол

а в чем проблема laravel и хайлод? оверхеды минимальные

Из фреймворков тормознее ларвела только symfony, даже тесты были

да все эти бенчмарки - взяты вообще с левых задач и примеров

несколько rest\protobuf api нод и там уже не столь важно ларавел там или что иное

на практике все работает совершенно иначе

в хайлоаде решает не скорость выполнение скриптов

в хайлоаде решает скорость выполнения скриптов

лол)

именно что скорость работы логики приложения и решает

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

можно писать хоть на ассемблере, только дольше и сложнее. не одними только бенчами стек технологий определяется

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

лооол

при чем тут хайлоад

да все эти бенчмарки - взяты вообще с левых задач и примеров

Чем больше абстракций, интерфейсов и наследований тем тормознее всё работает

лучше 100к подключений со скоростью выполнения 2 секунды, чем 1к со скоростью выполнения 0.05

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

Чем больше абстракций, интерфейсов и наследований тем тормознее всё работает

Кто тебе такое сказал

абстракции, интерфейсы и наследования - это все для исключения дублирования кода

Чем больше абстракций, интерфейсов и наследований тем тормознее всё работает

Мерил лично поди небось))

лучше 100к подключений со скоростью выполнения 2 секунды, чем 1к со скоростью выполнения 0.05

что за цифры с неба вообще

все зависит от приложения

может мне нужно менее чем за секунду запрос обрабатывать

ничто не мешает хайлоад масштабировать и добавлять ресурсы

ничто не мешает хайлоад масштабировать и добавлять ресурсы

горизонтально

да

вопрос лишь в том, насколько быстро отработает логика

а количество обрабатываемых запросов - это уже масштабирование

Давайте, не будем холиварит на эту тему, это бесполезно. У каждого своя кухня. На моей кухне так выгоднее, от монолита php переходить на микросервисы на lumen. А уж потом по одному хоть на пйтон хоть на си переписывать.

какая разница где микросервисы

лол

это паттерн а не реализация

в таблице topics - topicable_id и topicable

Тут такой вариант тоже не подходит, думаю

и SOA и монолит может работать с одинаковой скоростью

ERROR: S client not available

вопрос лишь в проблема масштабирования такого приложения

и SOA и монолит может работать с одинаковой скоростью

Может, но его поддерживать сложнее

это зависит от приложения

даже в крупном приложении не всегда SOA уместен

это зависит от приложения

1,5 строк кода на php с 2000 года

даже в крупном приложении не всегда SOA уместен

Согласен

фолли ваще на Yii пишет, не слушайте изменника

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

хайлоад кстати

ну, в перспективе

обработка кучи уведомлений

кучи - это миллионы в минуту?

ну

десятки тысяч в секунду возможно

Так что с вопросом, в ларавеле для партиционирования ничего такого нету ?

не позскажу по твоему вопросу

И никто из здешних я так понимаю с этим в ларе не сталкивался?

не люблю когда приходят с готовой базой и вообще всем на ларавель и просят от него сделать как им надо))

надо на ларавел, делай как там принято

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

Так что с вопросом, в ларавеле для партиционирования ничего такого нету ?

это же фишка у бд

а не у фреймворка на пыхе)

Ну "псевдо"-партиционирование

На стороне mysql не никакого партиционирования, к сожалению. Тогда бы и вопрос отпал

legacy код решал это описанием все таблиц во FROM

лучше "псевдо" не городить)

тобишь join'ами

лучше "псевдо" не городить)

Это понятно. Но не у всех как у вас все так просто, алтер тейбл сделал и пили дальше.

Тут альтер запросы, равноценны выстрелу себе в ногу

я вот думаю, как мне делать гейтвей для апи

нужна быстрая софтина обрабатывающая апи токен

Был докладик на эту тему в том году, на Highload'e