Парень создал систему поиска работы при помощи Claude Code

Которая в итоге отправила более 700 заявок и помогла найти работу. 🥳

Он выложил её в опенсорс.

Она автоматизирует весь процесс: сканирует страницы вакансий разных компаний, адаптирует твоё резюме под каждую конкретную позицию и даже автоматически заполняет формы за тебя. В репозитории есть:

- 14 различных режимов (оценка, парсинг, PDF и т.д.)
- терминальный dashboard на Go
- генерация PDF-резюме, оптимизированного под ATS, через Playwright
- уже более 45 настроенных компаний (Anthropic, OpenAI, ElevenLabs, Stripe…)

👉 @SQLPortal

Real-Time Dashboard для PostgreSQL прямо в терминале: https://github.com/mujib77/cosmo

Просматривай внутреннее состояние базы данных напрямую: запросы, записи, блокировки и подключения — всё в одном интерфейсе.

TUI для терминала, написанный на Go, который подключается к Postgres и показывает, что происходит внутри базы данных. Он читает системные представления вроде pg_stat_activity и pg_stat_database, обновляя данные каждые две секунды, и в реальном времени отображает метрики: активные запросы, cache hit rate, скорость записи WAL и ожидания блокировок.

Интерфейс разделён на четыре панели:
- Overview
- Queries
- WAL/MVCC
- Locks

👉 @SQLPortal

🚫 НИКОГДА не используй COUNT для проверки существования
Если тебе нужно просто проверить, существует ли конкретный элемент в данных, не используй COUNT() с фильтром (WHERE).

SELECT COUNT(*)
FROM users
WHERE email = 'http://thisemaildontexist.com'

Проблема в том, что COUNT(*) отвечает на другой вопрос. Он считает количество строк, которые удовлетворяют условию, хотя тебе нужно только знать, есть ли хотя бы одна.
Когда ты используешь COUNT(*), база данных может просканировать все подходящие строки, чтобы вычислить итог. Даже если она найдёт одно совпадение сразу, она может продолжить работу, потому что ты запросил полный подсчёт. Это лишняя работа при больших таблицах.

Вместо COUNT() используй EXISTS

SELECT EXISTS (
 SELECT 1
 FROM users
 WHERE email = 'http://thisemaildontexist.com'
);

С EXISTS база данных остановится, как только найдёт первое совпадение. Без подсчёта. Без лишнего сканирования.

👉 @SQLPortal

Чистые данные — это основа надёжной аналитики. SQL упрощает работу с NULL-значениями, дубликатами, выбросами, проблемами форматирования, опечатками и несогласованными значениями перед анализом или построением отчётности. Хорошие навыки очистки данных повышают точность и качество принимаемых решений. #SQL #DataAnalytics #DataCleaning #DataScience

👉 @SQLPortal

Почему запрос

SELECT * FROM users WHERE status <> 'banned';

не возвращает Charlie, если у него status = NULL?

Потому что в SQL NULL означает «неизвестное значение», а не пустую строку и не какое-то конкретное значение.
Когда SQL проверяет условие:

status <> 'banned'

для строки, где:

status = NULL

результат будет не TRUE и не FALSE, а UNKNOWN.
То есть SQL не может определить, равно ли неизвестное значение 'banned' или нет.

Получается:

NULL = 'banned'    → UNKNOWN
NULL <> 'banned'   → UNKNOWN

А в секцию WHERE попадают только строки, для которых условие вернуло TRUE.

TRUE     → строка возвращается
FALSE    → строка отбрасывается
UNKNOWN  → строка тоже отбрасывается

Поэтому Charlie не попадает в результат.
Если нужно включить строки с NULL, условие следует написать так:

SELECT *
FROM users
WHERE status <> 'banned'
   OR status IS NULL;

или в некоторых СУБД (например, PostgreSQL):

SELECT *
FROM users
WHERE status IS DISTINCT FROM 'banned';

Этот оператор рассматривает NULL как отдельное значение и вернёт все строки, где статус не 'banned', включая NULL.

👉 @SQLPortal

Для выполнения ad-hoc-поиска по данным в форматах JSON и XML можно создавать поисковые индексы.

В Oracle AI Database 26ai синтаксис был упрощён до:

CREATE SEARCH INDEX ... ON ... ( { xmlcol | jsoncol } )

Это позволяет выполнять полнотекстовый поиск по значениям XML- и JSON-документов с использованием индекса, что значительно ускоряет запросы по неструктурированным данным.

👉 @SQLPortal

Кодируйте строки на основе их произношения в Oracle AI Database 26ai с помощью:

PHONIC_ENCODE ( DOUBLE_METAPHONE[_ALT], <str> )

Это позволяет сопоставлять строки с разным написанием, которые звучат одинаково.
Например: "Knight" и "Night".

👉 @SQLPortal

«Потому что на этом этапе мы не обязательно знаем это наверняка» — комментарий из коммита 2004 года, который до сих пор присутствует в PostgreSQL.

Скриншот вверху взят из файла analyze.c в исходном коде PostgreSQL. Число 300 — это жёстко заданное значение в коде ANALYZE. Его происхождение связано с научной работой "Random Sampling for Histogram Construction: How Much Is Enough?", опубликованной в 1998 году, когда объёмы данных были значительно меньше, а оборудование — намного медленнее.

В статье рассматривался вопрос:

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

Ответ оказался примерно таким: около 300 выборок на каждый бакет (bin) гистограммы равной высоты (equi-height histogram).

Почему именно столько?
Статья показывает, что необходимый объём выборки растёт линейно с количеством бакетов, но лишь логарифмически с размером таблицы в большинстве практических случаев. Поэтому после нескольких сотен выборок на бакет отдача от увеличения выборки становится всё меньше.

Например, значение statistics_target по умолчанию равно 100.
Это означает, что PostgreSQL стремится собрать выборку размером:

300 × 100 = 30 000 значений

чтобы:

- построить гистограмму равной высоты из 100 бакетов;
- сохранить 100 наиболее часто встречающихся значений (Most Common Values, MCV).

Зачем столько усилий ради неиндексированных данных?

Потому что в 1998 году индексы были значительно дороже, чем сегодня:

- занимали ценное дисковое пространство;
- потребляли ограниченные IOPS при записи и построении;
- были дорогими в сопровождении;
- полные сканирования таблиц выполнялись медленно и блокировали работу.

В то время производительность дисков измерялась в RPM (оборотах в минуту). Говорить об IOPS было сложнее, поскольку случайный доступ к данным требовал ожидания поворота диска до нужного сектора, а физическое расположение данных заранее было неизвестно.

Тесты из статьи выполнялись на системе со следующими характеристиками:

- процессор Pentium 200 МГц;
- 64 МБ оперативной памяти;
- SCSI-диск 7200 RPM.

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

Компромисс между точностью и производительностью

Авторы статьи также отмечают, что задача является:

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

Поэтому:

«мы разработали простой метод оценки, который, по нашему мнению, является оптимальным».

Число 300 представляет собой компромисс между точностью и скоростью работы:

- меньшее значение дало бы менее точную статистику и могло привести к ошибочным решениям планировщика запросов;
- большее значение улучшило бы точность, но замедлило бы работу ANALYZE.

А в те времена ANALYZE и без того работал значительно медленнее.
Что контролирует statistics_target?
Параметр statistics_target определяет количество значений, сохраняемых для:

- Most Common Values (MCV);
- Equi-height Histogram.

Например:

statistics_target = 100  →  30 000 выборок, 100 MCV, 100 бакетов
statistics_target = 500  → 150 000 выборок, 500 MCV, 500 бакетов
statistics_target = 1000 → 300 000 выборок, 1000 MCV, 1000 бакетов

По умолчанию этот параметр задаётся на уровне базы данных, но его можно переопределить для отдельного столбца:

-- Настройка для конкретного столбца
ALTER TABLE requests
ALTER COLUMN status_code
SET STATISTICS 500;

ANALYZE requests;

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

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

👉 @SQLPortal

Lost update возникает, когда один пользователь незаметно перезаписывает изменения другого пользователя.

Vlad Mihalcea подробно разбирает:

• Как возникают lost update
• Как предотвращать их с помощью pessimistic locking (stateful) и optimistic locking (stateless)

Сейчас большинство приложений stateless, поэтому чаще используют optimistic locking.

👉 @SQLPortal

Решение многих распространённых проблем с производительностью БД вообще не требует изменений в самой базе данных. База — это лишь один компонент гораздо более крупной системы. В эту систему входят поведение пользователей, UX-дизайн, изменения в коде и меняющиеся сценарии использования.
Ниже — несколько проблем, которые выглядят как проблемы производительности БД, но на деле ими не являются.

Пользователи бесконечно жмут refresh

Когда пользователю кажется, что страница не загружается, он по привычке нажимает reload. Каждый reload повторно запускает те же самые запросы. Мы часто видели это на тяжёлых отчётах. Когда нагрузка была низкой, отчёты генерировались мгновенно, но с ростом числа клиентов, объёма данных и сложности логики запросы стали выполняться дольше, плюс выросло время форматирования на уровне приложения. Если кнопка “run report” никак не показывает, что процесс уже идёт, пользователи начинают нажимать её повторно или обновлять страницу.

Признаки:
• резкий рост calls в pg_stat_statements без соответствующего роста трафика
• всплеск запросов, привязанный к загрузке конкретной страницы
• пользователи жалуются, что страница «сломалась» или «грузится вечность»

Решение: состояния загрузки с отключением кнопок, optimistic UI, асинхронная генерация отчётов или хотя бы обычный spinner, который показывает, что приложение работает. Ни одна база не выдержит фронтенд, позволяющий пользователям DDOS’ить её вручную.

N+1 запросы из ORM

Вы загружаете список из 100 заказов. ORM затем выполняет ещё 100 отдельных запросов, чтобы получить клиента для каждого заказа. Потом дашборд показывает общее число заказов для каждого клиента — и это ещё 100 запросов. В итоге вместо одного запроса страница делает 201.

Каждый запрос занимает 2 мс. Но 201 × 2 мс = 404 мс последовательных round-trip’ов к БД на каждый запрос страницы. При 500 запросах в минуту одна страница генерирует тысячи лишних запросов в минуту, которых вообще не должно существовать.

Решение: свести всё к одному запросу через JOIN и агрегации. Некоторые ORM умеют это автоматически, в других придётся писать SQL вручную.

Агрессивный polling чаще, чем меняются данные

Разработчик добавляет setInterval(() => fetchStatus(), 1000) для проверки статуса заказа. Код уезжает в production. 50 000 активных сессий, опрашивающих сервер раз в секунду = 50 000 запросов в секунду к таблице, которая обновляется всего раз в минуту.

Решение: WebSocket, Server-Sent Events или хотя бы существенно увеличить интервал polling’а.
Запрос медленный только для нового сценария использования

Отчётный запрос выполняется 800 мс. Финансовый отдел запускает его один раз в день в 9 утра. Потом кто-то добавляет этот запрос в widget на дашборде с автообновлением каждые 30 секунд. Теперь каждый пользователь с открытым дашбордом запускает запрос на 800 мс по 120 раз в час.

Сам запрос медленнее не стал. Изменился паттерн доступа.

Решение: кешировать отчёт через materialized view, вынести его в background job или убрать auto-refresh.
Иногда проблема — в дизайне системы, а не в БД

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

👉 @SQLPortal

9 HTTP-методов

1. GET
Читает данные без их изменения.
Безопасный и идемпотентный — повторный запрос возвращает тот же результат.

2. POST
Создаёт новые ресурсы.
Не является идемпотентным — повтор может привести к дублированию данных.

3.PUT
Создаёт или полностью заменяет ресурс по известному URL.
Идемпотентный, идеально подходит для полных обновлений.

4. PATCH
Используется для частичных обновлений, изменяя только нужные поля.

5. DELETE
Удаляет ресурс.
Идемпотентный — повторное удаление не приведёт к ошибке. Часто используется в API для удаления записей.

6. HEAD
Как GET, но возвращает только заголовки (без тела ответа).
Удобен для проверки наличия ресурса или метаданных.

7. OPTIONS
Показывает доступные HTTP-методы для ресурса.
Часто используется для CORS preflight-проверок.

8. CONNECT
Устанавливает туннель — в основном используется для HTTPS через прокси.

9. TRACE
Возвращает полученный сервером запрос "как есть".
Нужен в основном для отладки

👉 @SQLPortal

Supabase выпустила бесплатный курс по изучению PostgreSQL с нуля и пошагово.

✓ Более 5 часов контента в 39 видео
✓ Запросы, JOIN, JSON, индексы и создание таблиц
✓ Всё объясняется постепенно и на практических примерах

https://databaseschool.com/series/intro-to-postgres/videos/203

👉 @SQLPortal

Брух, визуализируй SQL-базы данных прямо внутри VS Code 🤯

👉 @SQLPortal

Когда в psql выполняется запрос и вы нажимаете Ctrl+C, клиент отправляет серверу запрос на отмену выполнения. Но как это работает?

Сервер не может использовать уже существующее соединение, потому что оно занято обработкой текущего запроса. Поэтому Postgres использует второе, временное соединение, которое работает по принципу «отправил и забыл», аналогично SIGINT. Этот механизм намеренно сделан максимально простым, потому что отмена должна срабатывать даже тогда, когда всё остальное зависло.

Все драйверы, клиенты и инструменты, поддерживающие отмену запросов, используют один и тот же механизм.
PID, секретный ключ и код запроса на отмену

Во время инициализации соединения, после завершения аутентификации, сервер отправляет сообщение BackendKeyData, содержащее:

pid — идентификатор процесса (PID) backend-процесса, обслуживающего ваше соединение;
secret — случайное 32-битное целое число, генерируемое при запуске сессии.

Согласованный код запроса на отмену — фиксированное значение: 0x04d2162e, или PG_PROTOCOL(1234,5678) в исходном коде Postgres.

Чтобы отменить запрос, клиент открывает новое соединение с портом Postgres и отправляет сообщение CancelRequest, содержащее PID, секретный ключ и код запроса на отмену.

Что делает сервер?

- Распознаёт сообщение как CancelRequest, а не как стартовое сообщение (StartupMessage);
- Находит backend-процесс с указанным PID;
- Проверяет совпадение секретного ключа;
- Отправляет сигнал SIGINT этому backend-процессу;
- Закрывает соединение для отмены, не отправляя никакого ответа.
- Backend-процесс получает SIGINT, что запускает механизм обработки прерываний в Postgres. После этого в

исходное соединение возвращается ошибка:

ErrorResponse: ERROR: canceling statement due to user request
ReadyForQuery

Что именно происходит внутри Postgres после получения запросом сигнала SIGINT — тема уже не для выходного чтения. Об этом поговорим в одном из постов на след неделе.

👉 @SQLPortal

9 типов баз данных:

1) Реляционные (Relational)
↳ Хранят структурированные данные в таблицах с заранее определённой схемой и поддержкой SQL-запросов.
2) Ключ-значение (Key-Value)
↳ Хранят данные в виде пар «ключ-значение» для максимально быстрых операций чтения и кэширования.
3) Документные (Document)
↳ Хранят данные в виде JSON-подобных документов с гибкой вложенной структурой.
4) Ширококолонковые (Wide-Column)
↳ Хранят данные в гибких семействах колонок для масштабируемых распределённых нагрузок.
5) Временных рядов (Time-Series)
↳ Хранят данные с временными метками для метрик, логов, событий и телеметрии в реальном времени.
6) Графовые (Graph)
↳ Хранят связи между сущностями, позволяя эффективно выполнять запросы по связанным данным.
7) Векторные (Vector)
↳ Хранят эмбеддинги для поиска по сходству и AI-ориентированного поиска информации.
8) Колоночные (Columnar)
↳ Хранят данные по колонкам, а не по строкам, что ускоряет аналитические запросы.
9) Поисковые (Search)
↳ Хранят индексированный текст и структурированные данные для быстрого полнотекстового поиска и ранжирования результатов.

Большинство современных систем используют сразу несколько типов баз данных.
По мере того как системы становятся всё более ориентированными на работу в реальном времени и AI, потребность в инфраструктуре для временных рядов заметно выросла.

👉 @SQLPortal

Многие до сих пор сравнивают PostgreSQL и MySQL так, будто разница между ними сводится к синтаксису SQL и производительности в бенчмарках.

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

PostgreSQL представляет собой единый интегрированный движок. Данные хранятся в heap-таблицах, версии строк поддерживаются через MVCC прямо внутри таблиц, а для журналирования используется единый WAL (Write-Ahead Log).

MySQL (если говорить про InnoDB) устроен иначе. SQL-слой отделён от движка хранения, данные хранятся в кластеризованном B-дереве, история изменений строк выносится в undo-логи, а сама система опирается сразу на несколько журналов: Undo Log, Redo Log и Binlog.

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

Именно поэтому вопрос «что быстрее: PostgreSQL или MySQL?» обычно не имеет смысла без контекста.

Это не просто две разные СУБД. Это две разные архитектурные философии, которые решают похожие задачи разными способами.

👉 @SQLPortal

Surya OCR выглядит очень мощно для открытой OCR-модели.

Что выделяется:

→ менее 1 млрд параметров
→ поддержка 91 языка
→ до 5 страниц в секунду на RTX 5090
→ работает на CPU, GPU и Apple MPS
→ 83.3% на бенчмарке olmOCR, один из лучших результатов среди моделей до 3B параметров

Surya OCR относится к классу Document Intelligence-моделей. Она не просто извлекает текст с изображения, но также умеет работать со структурой документов: PDF, сканами, таблицами, многостраничными документами и сложной вёрсткой.

Подходит для задач:

• OCR документов и PDF
• оцифровки книг и сканов
• RAG-пайплайнов
• обработки счетов и форм
• извлечения данных из таблиц
• подготовки датасетов для LLM

100% open source.

👉 @SQLPortal

Обновить одну таблицу, используя значения из другой таблицы через прямое JOIN-соединение в 26ai:

UPDATE <target_tab>
SET <target_col> = <source_col>
FROM <source_tab>
WHERE <join_condition>

Такие JOIN-соединения также можно использовать в операторах DELETE.

👉 @SQLPortal

Скиллы AI-агентов представляют собой набор инструкций в Markdown, которые объясняют, как выполнять определённую задачу.

Kris Rice создал библиотеку из более чем 100 скиллов для работы с Oracle AI Database, включающую практические примеры, лучшие практики и распространённые ошибки.

Получить их можно здесь: https://github.com/oracle/skills

👉 @SQLPortal

Я сократил расход токенов в Claude Code вдвое с помощью одного файла.
Замерял результат в течение недели.

Секрет прост: научить Claude выбирать модель в зависимости от задачи.

Haiku для массовых механических задач.
Sonnet для исследований и анализа.
Opus только там, где действительно требуется сложное рассуждение.

До этого токены тратились без разбора на любые задачи.

После настройки результат остался тем же, а расход снизился примерно вдвое.
Схема состоит из трёх частей.

1. Блок делегирования задач
Вы задаёте правило, по которому Claude создаёт субагентов и выбирает самую дешёвую подходящую модель:
→ Haiku: рутинные задачи без необходимости принимать решения
→ Sonnet: исследования, изучение кодовой базы, анализ и обобщение информации
→ Opus: только для реального планирования и сложных компромиссов

Два важных ограничения:
• Haiku никогда не создаёт собственных субагентов. Если это понадобилось, задача была плохо декомпозирована.
• Максимальная глубина вложенности — два уровня (родитель → субагент → ещё один уровень).
Если субагенту требуется более сильная модель, он возвращает задачу родителю, а не повышает уровень самостоятельно.

2. Блок предпочтительных инструментов

Вы учите Claude сначала выбирать самые дешёвые инструменты:
→ WebFetch для публичных веб-страниц
→ agent-browser CLI для динамических страниц и сайтов с авторизацией (примерно на 82% меньше токенов по сравнению с инструментами на основе скриншотов)
→ Конвертация PDF в текст вместо использования инструмента Read

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

3. Две строки в settings.json

"CLAUDE_CODE_DISABLE_1M_CONTEXT": "1"

Не позволяет загружать огромные контекстные окна, которые часто не нужны.

"CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "80"

Запускает автоматическое сжатие контекста при заполнении на 80%, а не после полного заполнения.

Только эти две настройки экономят токены в каждой сессии.
Вся настройка занимает около двух минут.
А экономия начинает накапливаться с каждой следующей задачей.

👉 @SQLPortal

Dolt — это SQL-база данных с полноценным Git-подобным контролем версий для данных.
Можно делать ветки, мержить изменения, форкать и клонировать не только код, но и сами данные.

• Подключение через MySQL-протокол, чтение и запись версионируемых данных обычным SQL
• Импорт CSV, коммиты изменений, push, pull и merge через привычные Git-команды
• Публикация баз на DoltHub или самостоятельный хостинг через DoltLab
• Используется как слой памяти для AI-агентов в multi-agent и multi-machine workflow

Если вам когда-нибудь хотелось сделать git checkout, git diff или git merge для базы данных, Dolt решает именно эту задачу.
Посмотреть проект можно здесь: https://github.com/dolthub/dolt

👉 @SQLPortal