Inferno solutions

Да их знаю. есть проблема.

у них нет VLAN

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

Почему через инет

Ну как мне сказала поддержка VLAN у них нет. и единственное решение поставить выделенные сервера

второго интерфейса нет

у них нет VLAN

Шта?

Как это в швабодке нет vlan?

Ну трафик всеравно не будет ходить в инет

Пойдет через их маршрутизатор в их же ДЦ

Есть такое дерево сущностей: Агент Клиент1 Пост 1 Коммент1 Соответственно у Агента может быть много Клиентов, у Клиентов может быть много постов, у Постов может быть много комментов Задача вывести для Агента таблицу: Клиент, Кол-во Постов, Кол-во комментов и чтобы по кол-ву постов и комментов можно было сортировать.

у меня мысль одна - делать вьюху

В чем проблема написать sql-запрос?

или два

Я бы добавил агрегационную таблицу которую обновлял кроном

Ну или два запроса

У доктрины есть фция SIZE

Может можно написать order by SIZE(agent.comments)

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

Я бы добавил агрегационную таблицу которую обновлял кроном

Ну или material view

Я бы добавил агрегационную таблицу которую обновлял кроном

Удачи

Вечера юмора в канале симфони)

Удачи

Рабочее решение если нужно много делать селектов и мало апдейтов и не важна супер констистентость

Ага ага

Что ага

В чем проблема написать sql-запрос?

Ну так напиши)))

Ага ага

А если что то конструктивное?!

Я бы добавил агрегационную таблицу которую обновлял кроном

Вопрос в том какие держать актуальной

Ну так напиши)))

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

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

Человеку больше кроном нравится

Парни, в чем проблема, давайте select from..

Как говорится на словах все львы толстые

Для меня вот проблема, она чё бы не задавал вопрос

Ну а масштабы хоть какие? Ну типа сколько может быть Клиентов, постов комментов у одного Агента? А то вдруг там по 100к постов и 1кк комментов и там тогда запрос точно никак не поможет

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

так пока никто не писал про миллионы комментов то) Задача поставлена в исходной формулировке как тест на собесе на знание SQL для джуна)

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

Евентами в коде обновлять таблицу со счётчиками... Или тригерры или ещё что то вроде редиса...

Прямая дорога к рассинхрону

Инкремент это атомарная операция - никакого рассинхрона

Прямая дорога к рассинхрону

Да и хрен с ним, если это не деньги.

Даже если вдруг рассинхрон - разве это важно?

Раз в сутки пересчитай точно и всё

Да и хрен с ним, если это не деньги.

+

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

Кеширование чуток сложнек реализовать чем крон с insert into select on duplicate update

Что по сути и есть кеширование на стороне бд

так пока никто не писал про миллионы комментов то) Задача поставлена в исходной формулировке как тест на собесе на знание SQL для джуна)

Ну на счет задачки для джуна это ты бощенул чот )

записей не миллиард но и не 100 штук

ну надо еще учесть планируемую нагрузку на метод

Кароч... Задачка эта делается как проще и быстрее... А потом когда начнёт тупить - переписывается нормально... На фиг этот оверинжинеринг...

Потом можно запилить хоть на отдельном микросервисе))

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

Короче решил делать предагрегаты, еще добавлю дату туда. буду хранить кол-во по дням, чтобы удобно было строить потом отчеты день\неделя, месяц и т.д.

А вы точно не занимаетесь преждевременной оптимизацией?

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

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

А вы точно не занимаетесь преждевременной оптимизацией?

Я выше об этом писал))

Джентльмены, пытаюсь с помощью https://symfony.com/doc/current/components/dom_crawler.html распарсить таблицу. Умеет ли данный компонент выбрать определенное количество элементов, а не всю таблицу? Если да, то каким образом?

Мне, например нужно первые 200 строк, а их более тысячи

Мне, например нужно первые 200 строк, а их более тысячи

Чем вам не подходит метод filter?

В xpath есть метод position() ->filterXpath(table > tr[position() < 200]); Как то так

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

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

Оно довольно таки тяжелое, не хотелось бы забивать память

Оно довольно таки тяжелое, не хотелось бы забивать память

Тогда лучше вообще отказаться от DomCrawler

Это ручник

Тогда лучше вообще отказаться от DomCrawler

Альтернативы?

DomXml

Альтернативы?

Миллион их. Память не хочется забивать потому что 10000rpm на бекенд или по идеологическим причинам? По моему опыту домкраулеры в один поток работают.

Миллион их. Память не хочется забивать потому что 10000rpm на бекенд или по идеологическим причинам? По моему опыту домкраулеры в один поток работают.

Rpm — обороты двигателя?)

Миллион их. Память не хочется забивать потому что 10000rpm на бекенд или по идеологическим причинам? По моему опыту домкраулеры в один поток работают.

А как оно на пыхе может не в один поток работать?

Например так

Ну это вроде как не из коробки и не на всяком хостинге заведётся... А так то конечно можно было бы как и многопоточность на CURL

Я кстати ещё ниразу не встречал "многопоточного дом-краулера" на пыхе

Я кстати ещё ниразу не встречал "многопоточного дом-краулера" на пыхе

обычно проще запустить несколько обработчиков очереди

обычно проще запустить несколько обработчиков очереди

Ну это понятно, я собственно так и делал)

Я даже штуку написал

https://github.com/zim32/workman

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

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