За 6 человекочасов два программиста уровня мидла накодили
лендос. С возможностью отправить заявку и посмотреть весь пул заявок.
ТГ бота в котором можно абсолютно бесплатно початиться с ChatGPT 4o (абсолютно бесплатно без хард лимитов).
Я посчитал что результат более чем достойный, поэтому решил написать пост, как мы ускоряли разработку чтобы так быстро забутстрапиться.
Давайте признаем, что иногда написание кода может быть сущим мучением. Все мы хоть раз смотрели на пустой экран, пытаясь вспомнить тот самый специфический синтаксис или в попытке отладить проблему, которая буквально выводила нас из себя.
Конечно, сейчас уже есть инструменты на базе искусственного интеллекта, такие как GitHub Copilot, ChatGPT и Claude, которые пытаются облегчить нам жизнь. Но давайте будем честны — они также заставляют нас желать большего.
Используя курсоры, вы сможете порционно получить из БД и обработать большое количество данных, не расходуя при этом память приложения. Уверен, перед каждым веб-разработчиком хотя бы раз вставала подобная задача, передо мной тоже — и не раз. В этой статье я расскажу, в каких задачах курсоры могут быть полезны, и дам готовый код по работе с ними из PHP + Doctrine на примере PostrgeSQL.
Изначально мы должны понять, почему подход с offset pagination не годится для больших датасетов с помощью следующего примера:
Клиент предоставляет два параметра — LIMIT для ожидаемого максимального количества результатов и OFFSET для смещения страницы. Например, с OFFSET = 400, LIMIT = 20, мы возвращаем из БД 20 items, выбрасывая первых 400.
Использование LIMIT и OFFSET плохо работает на больших датасетах. По мере того, как OFFSET возрастает, БД по-прежнему должна прочитать данные вплоть до OFFSET + нужного кол-ва записей с диска, до того как отбросит OFFSET и вернет только ожидаемое количество записей
Если записи поступают в БД с высокой скоростью, текущее окно становится ненадежным для страничного доступа, потенциально приводя к потере данных или возвращению дубликатов.
Решением этой проблемы может являться Cursor API, после каждого запроса возвращающее курсор, который может использоваться клиентом при запросе следующей/предыдущей порции данных.
Читать полностью »
Некоторые наши пользователи стали сообшать что репорты иногда возврашают значение превышаюшее 100% для показа роста данных.
При этом выяснилось что сервис, доставляюший данные от аппаратуры иногда делает пропуски в значениях.
Там где сервер читал аппаратуру напрямую, вместо значений вставлял NULL, а там где читал с использованием SNMP, там вставлял 0.
То есть ряд значений счетчика был как: 4, 10, 20, NULL, NULL, 31, 0, 0, 0, 50 а теперь надо 4, 10, 20, 20, 20, 31, 31, 31, 31, 50
Наверное можно было бы апроксимировать данные, но стэхолдеров это устраивает, а наше дело удовлетворять клиентов.
Что делать стало ясно, вопрос только на какой стороне что исправлять.
