Формальный непроцедурный язык программирования
Здравствуйте, уважаемые читатели Хабра!
В первой части мы рассказали, как решили задачу сегментации полигона дороги в PostGIS. А теперь рассмотрим сопоставление сегментов двух разных версий дороги для сохранения учёта историчности привязанных к ним событий.
Мне нравится чистый SQL.
Не «нравится, потому что пришлось», а правда нравится. В хорошем SQL‑запросе видно, что происходит с данными: откуда берём, как фильтруем, где соединяем, что агрегируем и в каком порядке отдаём наружу.
Но как только в API появляются фильтры, сортировка, пагинация и отдельный COUNT(*) с тем же WHERE, чистый SQL быстро обрастает ручной бухгалтерией: args, placeholder«ы, fmt.Sprintf и копирование условий между запросами.»
В какой‑то момент я понял, что меня раздражает не SQL. Меня раздражает работа вокруг SQL.
Так появился qrafter — небольшой type‑safe SQL query builder для Go: без ORM, без codegen, с типизированными колонками, зависимым от диалекта рендером и обычным SQL + аргументами на выходе.
Привет, Хаброжители! SQL, «структурированный язык запросов» (Structured Query Language) — это универсальное средство создания, управления и составления запросов к реляционным базам данных, таким как SQL Server, PostgreSQL и Oracle. Для аналитиков данных SQL — суперинструмент, позволяющий выйти за пределы обычных табличных редакторов и систем бизнес-аналитики. При этом язык SQL интуитивен и на удивление прост: немного практики во время чтения книги — и вы уже с легкостью извлекаете данные, перестраиваете таблицы и создаете яркие, наглядные отчеты и презентации!
Привет, хабровчане! Сегодня покажу, как писать расширения для PostgreSQL. На примере pg_plan_alternatives, который логирует все пути, рассматриваемые планировщиком. Вы увидите то, что обычно скрывает планировщик.
Типизированное хранилище для .NET поверх Postgres и MSSQL. C#-класс как схема — без миграций, без Include, с полным LINQ. Работает в проде.
Пятница, вечер. Один эндпоинт начал отвечать восемь секунд вместо двухсот миллисекунд, а в Grafana всё зелёное. PostgreSQL редко падает громко — он неделями копит мёртвые строки, лишние индексы и зависшие транзакции, пока не станет совсем плохо.
В статье — пять SQL-запросов из моего queries.sql, которыми я реально пользуюсь: bloat и dead tuples, топ тяжёлых запросов по pg_stat_statements, неиспользуемые индексы, висящие транзакции и блокировки. Работают на голом PostgreSQL 13+
Здравствуйте, уважаемые читатели Хабра!
В данной статье расскажем, как мы смогли автоматизировать процесс разбиения дорог в PostGIS, тем самым снизив нагрузку на специалистов и в разы увеличив скорость обработки полигонов.
Меня зовут Евгений Ефимкин, я руковожу группой Platform Reliability в Yandex Cloud. В числе прочего мы занимаемся безопасностью наших managed‑сервисов.
В managed PostgreSQL мы не выдаём клиенту привилегии superuser — иначе он сможет выйти за пределы своей базы прямо в операционную систему. Чтобы клиент при этом мог выполнять привилегированные операции: создавать базы, заводить роли, менять настройки кластера, — мы пишем сервисы Control Plane и выдаём специальные ограниченные роли (без выхода в ОС и без обхода проверок прав).
Несколько лет назад, занимаясь поддержкой логической репликации, я понял, что и этого мало: у PostgreSQL остаются места, где он сам, изнутри, выполняет код от superuser в обход всей конструкции. Дальше — два случая повышения привилегий у двух разных публичных облачных провайдеров. Оба вектора к моменту публикации закрыты — и в апстриме PostgreSQL, и у самих сервисов; оба провайдера своевременно проинформированы.
В первой статье была описана задача распределения сумм затрат между отделами по заданным правилам, с учётом того что отделы могут передавать свои затраты на другие отделы. Задача этой и следующей статей — показать, как эту задачу можно реализовать относительно просто и легко, не прибегая к созданию больших приложений.
В данной статье будет описана структура PostgreSQL-базы данных и реализация данной задачи с помощью SQL в варианте PL/pgSQL. Реализация на Apache Spark будет описана в следующей статье.
В качестве примера будут созданы настройки распределения и входные данные для:
В этой статье я поделюсь опытом проектирования идентификаторов для крупной медицинской системы. Мы пройдем путь от простых автоинкрементов до UUID, ULID и в итоге создадим гибридное решение, которое оказалось лучше всех существующих подходов. Спойлер: идеальный ID — это не технология, а архитектура.
Привет! Я Ильдус Тукаев, разработчик в команде образовательной платформы Т-Банка. Мы помогаем школьникам, студентам, молодым специалистам и сотрудникам получать знания и качать свои софт и хард навыки. Основной язык у нас Go, но сегодня расскажу больше про архитектурную тему: как у нас в команде использовался паттерн Outbox и как он эволюционировал.
За полтора года реализация Outbox прошла четыре итерации. По пути мы ловили VACUUM, который останавливал сервис на три часа, теряли 5% событий за полтора дня и заваливали поддержку обращениями. Расскажу, какие реализации мы пробовали, на какие грабли наступали и почему остановились на варианте, который сами же не считаем идеальным.
LEFT JOIN считается одной из самых безопасных конструкций в SQL — пока один фильтр в WHERE тихо не превращает его в INNER JOIN. Ошибка коварная: запрос выглядит абсолютно нормальным, результаты приходят, база не ругается, а часть строк уже исчезла.
В статье разбираем, почему это происходит, как NULL ломает ожидания и чем на самом деле отличаются условия в ON и WHERE.
В прошлой статье я рассказывал, каково в одиночку тащить фуллстек-проект, который разросся до кино-соцсети. В комментариях несколько раз спросили про конкретику — «покажи код», «как сделал, что не выглядит как очередной пет-проект». Логично: дизайн — это то, по чему встречают. Поэтому держите вторую часть, уже техническую и с кодом. Без маркетинга, только решения, которые реально сделали интерфейс «дорогим», и пара бэкенд-хитростей в довесок.
Сразу дисклеймер: я не дизайнер. Всё нажито методом «смотрю на референсы (Letterboxd, Mubi, KinoPoisk HD) и пытаюсь повторить ощущение». Оказалось, премиальность — это не про дорогие шрифты, а про несколько повторяющихся приёмов. Разберём пять.
1. Акцентный цвет из постера фильма — фича, которая дороже всего «продаёт»
Самое заметное решение. Раньше у меня на всех страницах был один статичный фиолетовый акцент — и это выглядело дёшево и одинаково. Идея: пусть каждая страница фильма подсвечивается доминантным цветом его постера. Заходишь на мрачный нуар — интерфейс уходит в холодный синий, открываешь комедию — тёплый янтарь. Страница будто «сделана под этот фильм».
Делается без всяких ML, прямо в браузере через canvas: рисуем постер в крошечный буфер 32×48, усредняем цвета (выкидывая чёрные рамки и серость), переводим в HSL и принудительно «насыщаем», потому что постеры часто тусклые. Результат кладём в CSS-переменную — и весь интерфейс подхватывает её.
Продолжаем серию публикаций «Адаптивное администрирование Sigla Vision».
В предыдущей статье мы изложили основную концепцию построения объектной модели (ОМ), подробно разобрали сборку данных таблиц и привели код для ее развертывания.
В этом материале расскажем, как построить систему версионирования для репозитория метаданных Sigla Vision (БД FineDB). Самой FineDB такая информация недоступна — там в основном данные только о текущем состоянии системы.
Версионирование помогает оценить реальное использование таблиц и увидеть динамику объектов. На основе исторических данных у нас построено несколько системных отчетов, которые мы регулярно используем в работе.
Описанный подход не привязан к Sigla Vision — он применим к любой аналитической системе, где метаданные хранятся во внешней СУБД с поддержкой триггеров.
В SQL самые опасные ошибки часто выглядят как рабочие запросы. Они не падают, не ругаются на синтаксис и не подсвечиваются в IDE — просто возвращают пустоту там, где должны быть данные.
В этой статье разберём классическую ловушку NOT IN: почему один NULL в подзапросе может «отравить» всю выборку, чем IN на самом деле отличается от NOT IN и почему в таких случаях безопаснее писать через NOT EXISTS.
Взгляд на экосистему SQL-разработки под MS SQL SERVER через призму контроля качества кода. Обзор существующих инструментов, описание самостоятельной наработки для линтинга T-SQL кода.
Сегодня SCD-2-таблицы не только остаются актуальными для медленно меняющихся данных, но и, на мой взгляд, становятся гораздо проще в реализации благодаря новым технологиям и инструментам.
Мне поручили пересобрать витрину в ходе миграции в наше новое хранилище данных. Итак, в этой статье мы будем:
— строить Iceberg-таблицы SCD-2 с помощью Trino, SQL и Python;
— попутно освоим прекрасные функции merge, MD5 и другие полезные инструменты;
— напишем свой собственный оператор для Airflow для автоматизации ETL-процесса.
Привет, Хабр!
SUM() OVER (ORDER BY ...) часто выглядит как очевидный способ посчитать нарастающий итог, пока в данных не появляются одинаковые значения ключа сортировки. В этот момент результат начинает «прыгать», LAST_VALUE возвращает текущую строку, а запрос формально остаётся корректным.
В статье разбираем скрытую причину таких сюрпризов — кадр оконной функции: как база подставляет его по умолчанию, чем ROWS отличается от RANGE и какие детали стоит проверять, чтобы аналитические SQL‑запросы считали именно то, что вы ожидали.
Хабр, привет! Меня зовут Андрей Вихров, я создавал аналитические системы и внедрял data governance (DG) в крупных компаниях больше 15 лет, а сейчас занимаюсь метаданными в Data Office МТС. Тема порядка в данных для меня не нова, а какие выгоды можно извлечь из нее сегодня — стоит отдельного рассказа.
В компании накоплен огромный массив данных — только в дата‑каталоге зарегистрировано более 500 тысяч таблиц. С ними ежедневно работают сотни специалистов: от продуктовых аналитиков до инженеров данных, строящих витрины для ML‑моделей.
Но в каталоге описаны в основном таблицы — их назначение, поля, владельцы, а вот терминов и тем более их связей на порядок меньше. И это объяснимо: формировать термины сложнее, в производственный процесс они вписываются с трудом, а польза от них неочевидна.
Поэтому каталог чаще всего помогает находить описания по уже известной таблице, но не ответы на конкретные бизнес‑запросы. С ними аналитику все равно приходится разбираться самому, изучая материалы и консультируясь с коллегами, что отнимает много времени.
Логичный выход — автоматизировать процесс. Но если опытный аналитик справляется (рано или поздно) с задачей в существующих условиях, то ИИ‑агент этого сделать уже не сможет, поскольку опирается только на метаданные.
В нашем случае сложились два фактора. За годы работы над DG мы накопили экспертизу в описании и структурировании метаданных. А появление LLM дало возможность создавать семантические слои на промышленной основе и использовать их для ответа на вопросы пользователей. Объединив одно с другим, мы создали и пилотируем систему Метан (метаданные + аналитика).
Уже совсем немного осталось до выхода релиза СУБД Tantor Postgres 18, и мы хотим наперед рассказать о его новых возможностях для работы с приложениями на платформе "1С:Предприятие". В обзоре разберем улучшения планировщика, по традиции коснемся работы временных таблиц и не обойдем вниманием вспомогательные утилиты, которые упрощают поиск и диагностику проблем в высоконагруженных системах. За каждым пунктом - реальные запросы 1С, реальные рабочие базы и сотни часов тестирования!