Sql базы данных

🖥 Text-to-SQL ломается не из-за модели. Он ломается из-за схемы Большинство думает, что проблема в LLM или плохом промпте. На практике всё проще. Модель не видит правильные связи между таблицами. Пример. Запрос вроде “какие издатели получили выплаты выше 5000”. Векторный поиск подтянет publisher и royalty_ledger. Всё логично. Но пропустит vendor_agreement, ту самую таблицу, которая их связывает. В итоге SQL выглядит валидно. Но возвращает ноль строк. Это системная проблема всех решений на embeddings. Они ищут по смыслу, но не понимают структуру базы. Нормальный подход другой. Схему нужно рассматривать как граф. Таблицы это узлы. Foreign keys это связи. Запрос решается не поиском похожих слов, а обходом графа и поиском join-пути. Именно так работает QueryWeaver. Он строит граф базы и при запросе сам находит весь путь, включая промежуточные таблицы. Даже если это цепочка из нескольких шагов. На практике это выглядит так. В тесте с базой на 60 таблиц он разобрал 5-шаговый запрос через цепочку superpower → capability_matrix → stakeholder_registry → resource_requisition → budget_allocation. Векторный поиск увидел только начало и конец. Всё между ними потерял, потому что “stakeholder” никак не связан по смыслу с “superpower”. Графу на это всё равно. Он просто находит единственный путь между сущностями. И это меняет всё. Open-source, можно развернуть у себя и наконец получить text-to-SQL, который реально работает. https://github.com/FalkorDB/QueryWeaver

Разрозненные инструменты, ручные операции, переключение консолей и долгий поиск причин сбоя — знакомая проблема для команд без единой среды администрирования. Postgres Pro Enterprise Manager 2.5 помогает навести порядок. Это графическая платформа для управления базами данных Postgres Pro через веб-интерфейс. С новой версией команда тратит еще меньше времени на рутину и быстрее возвращает систему в нормальный режим. Преимущества для бизнеса: ✔️ Ниже нагрузка на администраторов и меньше ручных операций. ✔️ Больше порядка в работе с экземплярами, ролями и бэкапами. ✔️ Быстрее поиск причин сбоев и проще восстановление. ✔️ Более управляемая инфраструктура и предсказуемая работа команды. Что нового в версии 2.5: ✔️ BiHA-кластеры: мажорное обновление через GUI, улучшенная интеграция и поддержка узла-рефери. ✔️ Аудит и контроль доступа: аудит CRUD-операций, детали изменений, работа с ролями СУБД через формы. ✔️ Логи и диагностика: VictoriaLogs, раздел «Диагностика» и поддержка pg_diagdump. ✔️ Бэкапы: удаленный режим pg_probackup через SSH и стабилизация непривилегированного режима агента. Запросите тестирование и проверьте Postgres Pro Enterprise Manager 2.5 на своей инфраструктуре. Реклама ООО «ППГ» Инн: 7707083893 Erid: 2Vtzqwfck23

Edit Banana редактирует текст прямо на картинках за пару кликов. Нейросеть разбирает изображение на смысловые блоки, после чего любой фрагмент можно переписать, не трогая остальное. Модель уверенно справляется с таблицами, формулами и диаграммами, сохраняет исходные цвета, шрифты и позиции элементов. Готовый результат экспортируется в DrawIO, SVG или PowerPoint. Проект полностью открытый, ставится локально с GitHub. Забираем, пока не закрыли: https://github.com/BIT-DataLab/Edit-Banana

🔥 NornicDB: База данных, которая объединяет Graph + Vector и летает в sub-ms Это гибрид: Graph + Vector + Temporal MVCC в одном ядре заточен под AI-агентов и knowledge systems Что внутри: • HNSW поиск <1ms • graph traversal без тормозов • writes тоже быстрые, не только чтение Из хорошего, это не Frankenstein из разных сервисов, а единая система. Под капотом: • Neo4j-compatible (Bolt + Cypher) • vector search как first-class citizen • GPU acceleration T- emporal модель с версионированием данных То есть ты можешь: • искать эмбецдинги • ходить по графу • делать time-travel запросы • всё это в одном запросе. Фактически это попытка сделать “память для AI”: где есть связи, смысл и история изменений, а не просто таблицы. Если делаешь RAG, multi-agent системы или сложные knowledge graph - будет полезно. GitHub: https://github.com/orneryd/NornicDB

⚡️ Вышло большое обновление популярного курса- Ai AI агенты, которые реально работают в проде! Вы всё ещё пишете обёртки над ChatGPT и называете это «AI-продуктом»? Пока вы промптите - рынок переходит на агентные системы. Те, что принимают решения, ходят в API, работают с Postgres и Redis, управляют браузером через Playwright. И 90% таких систем ломаются между ноутбуком и продом. AI Agents Engineering - курс, который закрывает этот разрыв. LangGraph, AutoGen, Computer Use, LLMOps. 8 модулей, 120+ шагов - от архитектуры до деплоя в Docker. На выходе: реальный опыт на большой практической базе, а production-агент и навыки, за которые уже платят. 👉 48 часов действует скидка на курс 55 процентов: https://stepik.org/a/276971/

Не пиши SELECT DISTINCT, если проблему создаёт плохой JOIN Частая ошибка - сначала размножают строки джойном, потом сверху лечат это DISTINCT. Это дорого и часто убивает план. Плохо:

    
        
SELECT DISTINCT u.id, u.name
FROM users u
JOIN orders o ON o.user_id = u.id
WHERE o.created_at >= CURRENT_DATE - INTERVAL '30 days';
{}
    

Лучше так:

    
        
SELECT u.id, u.name
FROM users u
WHERE EXISTS (
    SELECT 1
    FROM orders o
    WHERE o.user_id = u.id
      AND o.created_at >= CURRENT_DATE - INTERVAL '30 days'
);{}
    

DISTINCT часто добавляет sort или hash aggregation на огромном объёме. EXISTS превращает задачу в semijoin: • оптимизатору проще остановиться на первом совпадении • меньше памяти, меньше лишних строк, стабильнее план Это один из тех рефакторингов, который на больших таблицах реально даёт заметный буст.

Трансформация профессии разработчика в эпоху ИИ Профессия разработчика меняется прямо сейчас: ИИ уже пишет код, предлагает архитектуру и собирает прототипы за минуты. Но без фундаментальных знаний архитектуры, алгоритмов, сетей, безопасности и DevOps использовать такие инструменты рискованно. Центральный университет запускает серию бесплатных вебинаров о том, как меняется роль разработчика в 2026 году, какие навыки остаются критически важными и как безопасно и эффективно использовать нейросети в разработке. На вебинарах разберем: — почему ИИ не заменит программиста, но изменит его роль; — какие навыки и языки будут востребованы; — чего ждут работодатели от разработчиков сегодня; — почему магистратура по бэкенд-разработке может стать преимуществом; — как вырасти в техлида и тимлида, не теряя технических экспертных знаний. Спикеры — лидеры индустрии из Центрального университета, Авито и cloud. ru. Даты вебинаров: 21, 23 и 27 апреля 2026, 19:00 мск. Регистрируйся по ссылке

Ты до сих пор выбираешь базу данных по привычке? Вот 13 типов БД, которые нужно понимать, если хочешь проектировать системы нормально: 1) Реляционные Хранят структурированные данные в таблицах со схемой и работают через SQL 2) Key-Value Простейшие пары ключ-значение для максимально быстрых чтений и кеширования 3) Колоночные Хранят данные по колонкам, а не по строкам, идеально для аналитики 4) Wide-Column Гибкие колоночные семейства для распределённых систем и больших нагрузок 5) Документные JSON-подобные документы со свободной структурой и вложенностью 6) Векторные Хранят эмбеддинги, основа для AI, поиска по смыслу и RAG 7) Time-Series Данные с таймстемпами, метрики, логи, события 8) Immutable Ledger Нельзя изменить или удалить, только добавлять, используется для audit и финтеха 9) Графовые Оптимизированы под связи между сущностями, соцсети, рекомендации, fraud 10) Геопространственные Работают с координатами, расстояниями и картами 11) In-Memory Хранят данные в RAM, минимальная задержка и максимум скорости 12) Blob Для хранения файлов, изображения, видео, бинарные данные 13) Полнотекстовый поиск Индексируют текст и позволяют быстро искать по содержимому Реальность такая: нет лучшей базы данных есть база под конкретную задачу И чем раньше это понимаешь, тем меньше костылей потом в проде Какой тип используешь чаще всего сейчас? https://www.youtube.com/shorts/9QiasqVw-50

Продвинутый SQL совет - всегда проверяй, можно ли заменить SELECT DISTINCT на правильный JOIN или EXISTS. Очень часто DISTINCT добавляют просто чтобы убрать дубли после неудачного join. Запрос вроде работает, но по факту ты сначала раздуваешь результат, а потом заставляешь базу его чистить. На больших таблицах это легко убивает производительность. Плохой вариант:

    
        
SELECT DISTINCT u.id, u.name
FROM users u
JOIN orders o ON o.user_id = u.id;
{}
    

Лучше так:

    
        
SELECT u.id, u.name
FROM users u
WHERE EXISTS (
    SELECT 1
    FROM orders o
    WHERE o.user_id = u.id
);{}
    

Почему это сильный приём: EXISTS останавливается, как только находит первое совпадение не нужно тащить лишние строки не нужно потом убирать дубли логика запроса становится честной - ты проверяешь наличие, а не собираешь мусор Это один из самых частых hidden performance fixes в SQL. Если видишь DISTINCT, сразу спрашивай себя: он тут реально нужен или просто маскирует плохую логику JOIN.

🚀 PageIndex - умный индекс документов для reasoning-RAG (без векторов) PageIndex от VectifyAI - open-source система, которая помогает работать с длинными документами (PDF, тексты, правила и т.д.) так, как это сделал бы эксперт-человек, а не обычный поисковик. В отличие от традиционных RAG-систем, которые разбивают текст на куски и используют vector search (векторное сопоставление), PageIndex создаёт иерархическое дерево структуры документа и позволяет моделям ИИ логически искать ответы через reasoning и tree search. 📄 Основная идея - Длинные документы индексируются как семантическое дерево — похожее на умный «оглавление» - Структура сохраняет контекст и древовидную иерархию секций - При запросе модель обходит дерево через reasoning-поиск, как человек, который листает книгу по разделам, а не просто ищет по похожести текста - Не нужны: векторная база данных, chunking и top-K-селекция, что снижает потери контекста и повышает точность поиска 🧠 Почему это важно ✔️ Лучше для сложных и больших документов (финансовые отчёты, юридические тексты, технические мануалы) ✔️ Сохранение структуры означает, что ИИ может понимать, где именно в документе находится нужная информация ✔️ В отличие от vector-RAG, здесь решение не основано на похожести, а на пошаговом анализе структуры документа 🔧 Что внутри - Скрипты и Jupyter-ноутбуки для генерации дерева из PDF или Markdown - Возможность делать reasoning-RAG напрямую без внешних Vector DB - Примеры использования и cookbooks для практических сценариев PageIndex - это не просто индекс, а иерархический, reasoning-ориентированный RAG-фреймворк. Он позволяет ИИ читать и анализировать документы, как эксперт, обходя ограничения простого векторного поиска в больших текстах. ▪ Github: https://github.com/VectifyAI/PageIndex ▪ Blog post: https://vectify.ai/blog/Mafin2.5