Операция PIVOT в SQL

PIVOT - это операция, которая позволяет преобразовать строки в столбцы для создания сводных таблиц. Она используется для агрегации данных и суммирования значений в соответствии с заданными критериями.

Если вы работаете с диалектом SQL, который не поддерживает PIVOT, не волнуйтесь! Вы всё ещё можете достичь аналогичных результатов, используя операторы CASE.

Представлен проект ICQ Reborn. Это неофициальная сторонняя версия оригинального мессенджера, которая работает на собственном XMPP-сервере и доступна для бесплатной загрузки на ПК на Windows 10 и 11, а сам проект работает без шифрования.

#мессенджеры

⚡️ QueryTuner - open-source инструмент, который разбирает SQL-запрос и показывает, почему он может тормозить.

Подключаться к базе вообще не обязательно. Можно просто вставить SQL и получить диагностику.

Поддерживаются сразу 5 диалектов:

- PostgreSQL
- MySQL
- Oracle
- SQL Server
- SQLite

Внутри два уровня анализа.

1. Детерминированный heuristic engine

Он мгновенно ищет типичные anti-patterns:

- SELECT *
- функции внутри WHERE
- leading wildcard в LIKE
- потенциально отсутствующие индексы
- ORDER BY без ограничения результата
- другие проблемы производительности

Сейчас заявлено 12 правил, и для них не нужны ни LLM, ни внешний API.
2. Опциональный AI-слой

Можно подключить Qwen через Hugging Face или OpenAI. Тогда QueryTuner умеет:

- объяснять проблему человеческим языком;
- переписывать запрос;
- предлагать CREATE INDEX;
- объяснять, зачем конкретный индекс нужен.

Особенно интересно, что можно передать ещё и CREATE TABLE DDL. Тогда рекомендации становятся schema-aware: инструмент видит реальные таблицы, колонки и существующие индексы.

Например, для такого запроса:

SELECT *
FROM orders
WHERE YEAR(created_at) = 2026;

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

#SQL #PostgreSQL #Database #OpenSource #DataEngineering

https://github.com/AutoShiftOps/querytuner

⚡ В SQLite есть кусок кода, который выглядит «грязно», но оставлен таким специально ради скорости.

Каждый SQL-запрос SQLite сначала компилируется в байткод, а затем выполняется собственной виртуальной машиной VDBE.

Внутри — большой цикл диспетчеризации с почти 200 opcode.

И вот интересный момент: SQLite использует обычные goto, чтобы быстро прыгать между общими ветками выполнения.

В исходниках прямо написано:

«Код использует неструктурированные goto и выглядит не очень чисто. Но это сделано не из-за плохого стиля, так быстрее».

По замерам разработчиков, такой подход ускоряет sqlite3_step() примерно на 1,5%.

То есть здесь читаемость сознательно пожертвовали ради производительности.

Хорошее напоминание: в системном коде «красивее» не всегда значит «быстрее».

#SQLite #C #Databases #Performance #SystemsProgramming

🔥 PPT Master делает презентации из PDF, DOCX и сайтов прямо внутри Claude Code и Cursor. И на выходе это настоящий редактируемый PowerPoint

ppt-master работает как skill для AI-IDE. Можно просто написать: «сделай презентацию из этого PDF», после чего агент сам разбирает материал, продумывает структуру, собирает дизайн и экспортирует .pptx. Поддерживаются PDF, DOCX, URL и Markdown.

Самая сильная часть проекта в том, что слайды не превращаются в набор картинок. Текст, фигуры, таблицы и графики экспортируются как нативные объекты PowerPoint, которые можно открыть и вручную отредактировать. Есть шаблоны, live preview, анимации, speaker notes и даже генерация озвучки с последующим встраиванием аудио в PPTX.

Работает с Claude Code, Cursor, VS Code + Copilot и другими agent harness. Сам пайплайн выполняется локально, кроме обращений к выбранной AI-модели.

По сути:

PDF / DOCX / URL → AI-agent → структура → дизайн → настоящий editable .pptx

Автор отдельно пишет, что цель не заменить финальную ручную полировку, а убрать примерно 90% работы с пустого листа.

🔗 github.com/hugohe3/ppt-master

#AI #ClaudeCode #PowerPoint #Agents #OpenSource

🐘 SQL-совет, который многие игнорируют: не используй `COUNT(*)`, если тебе нужно только проверить существование строки.

Часто пишут так:

SELECT COUNT(*)
FROM orders
WHERE user_id = 42;

А потом проверяют, больше ли результат нуля.

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

Лучше использовать:

SELECT EXISTS (
    SELECT 1
    FROM orders
    WHERE user_id = 42
);

EXISTS может остановить поиск сразу после первого совпадения.

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

Если нужен ответ «да/нет» — не заставляй SQL считать всё.

SQLite-песочница в браузере

Чего мне всегда не хватало, так это аналога JSFiddle для SQLite, какой-то онлайн-песочницы, в которой можно быстро проверить SQL-запрос и поделиться с другими.

Смотреть статью

Линус Торвальдс написал и внёс изменения в драйвер графического ядра Intel Xe. Это произошло после того, как он столкнулся с «адской отладкой», но в итоге ему помог искусственный интеллект.

#ИскИн #ОС #разработка

Поиск таймаутов выполнения запросов SQL Server

Когда вы работаете с SQL Server, вы, вероятно, столкнулись с ситуацией, когда запрос занимает слишком много времени и в конечном итоге приводит к ошибке тайм-аута.

Вот некоторые советы для улучшения производительности и снижения тайм-аута:

- Используйте SQL Server Management Studio (SSMS) для управления и настройки SQL Server, а также для поиска таймаутов выполнения запросов. Используйте SQL Server Profiler для отслеживания и анализа производительности запросов.

- Используйте динамические управляемые представления, такие как sys.dm_exec_requests и sys.dm_exec_sessions, чтобы получить информацию о запросах, выполняемых на сервере, и определить, какие из них занимают слишком много времени.

- Используйте инструменты мониторинга производительности, такие как SQL Sentry, Idera SQL Diagnostic Manager и Microsoft System Center Operations Manager, для получения детальной информации о производительности сервера и запросов, выполняемых на сервере, и для получения рекомендаций по улучшению производительности и оптимизации запросов, чтобы избежать таймаутов выполнения запросов.

📌 Почему SQL работает именно так - заслуга Эдгара «Теда» Кодда

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

Кодд предложил хранить данные в виде математических отношений - знакомых нам таблиц. В 1970 году он описал реляционную модель и основные операции:

* σ - выбирает строки по условию, будущий WHERE
* π - оставляет нужные столбцы, основа SELECT
* ⋈ - соединяет связанные таблицы, будущий JOIN

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

SQL появился позже, но был построен на реляционной модели Кодда. Её принципы до сих пор лежат в основе большинства запросов к базам данных.

Два клиента одновременно бронируют один номер. Как не продать его дважды?

Обычная проверка «свободен ли номер?» может пропустить оба запроса: каждый успеет увидеть свободное время до сохранения чужой брони.

В PostgreSQL можно запретить пересечения прямо в базе:

CREATE EXTENSION IF NOT EXISTS btree_gist;

CREATE TABLE bookings (
    room_id   INT NOT NULL,
    starts_at TIMESTAMPTZ NOT NULL,
    ends_at   TIMESTAMPTZ NOT NULL,

    CHECK (ends_at > starts_at),

    EXCLUDE USING gist (
        room_id WITH =,
        tstzrange(starts_at, ends_at, '[)') WITH &&
    )
);

Как это работает:

• room_id WITH = — проверяем брони одного номера.
• WITH && — запрещаем пересечение временных интервалов.
• '[)' — начало включено, конец исключён. Брони 10:00–11:00 и 11:00–12:00 допустимы.
• CHECK — окончание должно быть позже начала.

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

Подходит для гостиниц, переговорных, аренды оборудования и записи к специалистам.

Энтузиаст попросил GPT-6 Astra и Claude Fable сделать для него бесплатный «аналог» Adobe Photoshop. На токены ушло $2000 или 168 тысяч рублей.

У моделей получилась работающая версия со слоями, масками, смарт-объектами, кривыми, эффектами и другими инструментами. Пользователь выложил программу для Windows 11, macOS и Linux — бесплатно

vc.ru/ai/3142780

3 AI-навыка для работы с архитектурой AI-систем

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

Навык 1: Работа с LLM API

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

Пример простой интеграции: приложение получает запрос от пользователя, отправляет в Claude API с заданной температурой (контролирует креативность ответа) и максимальным количеством токенов, получает ответ в потоковом режиме (streaming) и отдаёт его пользователю по частям.

Инструменты: официальные API OpenAI, Anthropic, OpenRouter (единый интерфейс к десяткам моделей), Google Gemini API.

Почему важно: базовый навык для любого AI-инженера. Без него следующие два навыка просто не имеют смысла — RAG и выбор моделей надстраиваются именно поверх API.

Навык 2: Построение RAG-систем

RAG-системы подключают к языковой модели собственную базу знаний: документы, инструкции, внутренние регламенты, статьи или переписку. Пользователь задаёт вопрос, система находит в вашей базе релевантные документы и отправляет их модели вместе с вопросом в промпте. Модель отвечает на основе ваших документов — а не общих знаний, которые могут быть устаревшими или неполными.

Инструменты: LangChain, LlamaIndex, векторные базы данных (Chroma, Pinecone, Weaviate).

Почему важно: чистая LLM знает то, на чём её обучили год назад. RAG — это работа с живыми, актуальными и корпоративными данными. Без него AI-продукт для бизнеса сегодня почти не построишь.

Навык 3: Оценка и выбор моделей под задачу

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

Инструменты: OpenRouter (сравнение моделей по цене и скорости), бенчмарки SWE-bench, AIME, собственные бенчмарки на ваших данных.

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

📌 Сохраните, чтобы не потерять, и приходите качать AI-навыки в Практикум.

Журнал «Код» | Промокод Практикума | Новости мира IT и технологий