SQL *

Всем привет! Меня зовут Александр Цай, я ведущий инженер-аналитик в МТС Web Services.
Занимаюсь всем, что связано с данными и ИИ. Найти, заполучить, обработать, спроектировать, развернуть — это все ко мне.

Опущу все нудные подробности, решили мы развернуть себе Superset 6.1.0 — последнюю версию, но столкнулись с тем, что заказчику категорически не нравится штатный фильтр по датам и он не хочет пересаживаться со своего BI, а хочет он календарик. А еще — пару плагинов с оглядкой на PowerBI. Поэтому встал вопрос создания собственного плагина-фильтра.

Казалось бы, задача несложная. Пара-тройка гайдов в en сегменте имеется, есть даже документация и штатный генератор шаблонов. Но по факту оказалось, что все это не работает. Генератор так вообще не обновлялся аж с 2024 года: выдает шаблон, который ссылается на уже несуществующие классы и типы, что автоматически делает все гайды неактуальными…

А что все это значит? Время написать свой собственный!
Об этом и расскажу в сегодняшнем материале. 

Дисклеймер: Я питонист до мозга костей и в тайпскрипте, да и фронте в целом, понимаю не очень много. Простите меня, адепты сего языка программирования, но код самого плагина навайбкожен (хоть и проверен насколько я смог).
В npm не запушил тоже умышленно, цель статьи — дать исходники и показать, как можно собрать плагин. Любой желающий может что-то додумать и доработать, собрать или разобрать и так далее.

Документация PostgreSQL по numeric содержит два плохо согласующихся утверждения:

«especially recommended for storing monetary amounts and other quantities where exactness is required» — и сразу же: «calculations on numeric values are very slow compared to the integer types, or to the floating-point types». То есть рекомендуют для хранения денежных величин и тут же признают, что это весьма дорого.

Для меня, как разработчика СУБД это сигнал к действию. Если операции с типом заметно медленнее bigint, возникает соблазн: а нельзя ли хранить денежные величины целым числом копеек и округлять по стандартному правилу? Это бы прилично сэкономило вычислительные ресурсы наших серверов баз данных, разве нет? А что, если вообще использовать double precision?

Привет, Хабр!

Меня зовут Жуйков Андрей, занимаюсь развитием и продвижением СУБД Digital Q.DataBase.

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

В этой статье я покажу, как установить Digital Q.DataBase 18.2 на РЕД ОС 8.0.3, познакомлю с новой архитектурой СУБД и продемонстрирую подключение к каждому из поддерживаемых диалектов.

Если вы пишете SQL‑запросы, то наверняка сталкивались с ситуацией, когда данные исчезают, отчеты не сходятся, а бизнес теряет деньги. И виновник этого — маленькое, но очень коварное слово NULL. В 1974 году Эдгар Кодд, создатель реляционной модели данных, ввел это понятие, чтобы обозначить отсутствие информации. Он хотел, как лучше, но спустя пятьдесят лет NULL продолжает «терроризировать» разработчиков по всему миру. Важно усвоить раз и навсегда: NULL — это не значение. Это состояние неизвестности.

Поэтому:

· NULL ≠ 0 (ноль — это число);
· NULL ≠ '' (пустая строка — это строка);
· NULL ≠ ' ' (пробел — это символ).

Но всегда есть нюансы и исключения. Например, в Oracle INSERT INTO table (col) VALUES ('') запишет NULL. Это поведение отличается от других СУБД и часто становится сюрпризом при миграции.

Всем привет! Меня зовут Муса. Наша команда занимается витринами данных по товарному учёту.

Каждый день мы доставляем около 10 млрд записей в разных форматах. На этих данных строится различная аналитика, связанная с товарными запасами и движениями экземпляров. Перед нами встала задача: пять раз в день обогащать выгрузку из миллиардов экземплярных остатков дополнительными атрибутами для построения различного рода аналитики. История этих атрибутов уже измерялась десятками миллиардов записей.

Первое решение выглядело просто: положить данные в ClickHouse и сделать JOIN. Но одна выгрузка считалась около 12 часов, а нам нужно было укладываться в десятки минут.

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

Вслед за Эдвардом Сьоре, или как я писал свою реализацию on disk B+Tree-индекса на Rust. В этой статье попытаюсь осветить нюансы написание своего игрушечного индекса.

parquet - данные лежат в открытом формате - казалось бы, бери кто хочешь. Но есть неприметный артефакт, от которого зависит, увидите вы таблицы или мусор из файлов и кого вообще к ним подпустят. Это каталог. Разбираю просто, что такое Apache Iceberg, зачем ему каталог - и почему новость про Polaris важнее, чем кажется. В продолжение анонса новостей…

SELECT * FROM document, client(document)

запрос, который ходит по связям вместо ON. Как включить такую навигацию на ванильном PostgreSQL — без патчей, расширений и нового синтаксиса, — почему стандарт SQL не научился этому за сорок лет и кто пытался его дожать — под катом.

Когда приходишь на аудит СУБД к разным компаниям, картина удивительно похожа: одни и те же проблемы, одни и те же причины. Меня зовут Андрей, я DBA в группе поддержки системного ПО Центра экспертизы по комплексному сервису К2Тех, сертифицированный эксперт Postgres Pro. В этой статье представлен ТОП-10 ошибок, с которыми мы встречаемся чаще всего. Я разберу, чем они опасны, почему возникают, и как их можно решить. Скорее всего, многие пункты покажутся вам до боли знакомыми:

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

Всем привет! Меня зовут Саша, играю за команду 4Ray (НЕ ПУТАТЬ С СОЛАРОМ) в CTF и участвую в других активностях в ИБ, чаще всего выступаю под ником MN3STRASHN0. В этом материале представлен путь решения машины Rawmatex на платформе Standoff 365, она довольно простая, но всё равно требует внимательности, ведь поинты сами себя не заработают. В задании используется классическая цепочка уязвимостей, которая в итоге приводит к реализации недопустимого события. Статью готовили вместе с RedblueNotes (одноименные Хабр, и tg-канал) за что им огромное спасибо. Далее рассмотрим решение.

«Bad CaRMa» — глава из Dreaming in Code Скотта Розенберга (каламбур на CRM и «карму») про CRM-систему Vision в компании Upstart. Архитектор задумал предельно гибкую схему: одна-единственная таблица DATA, куда сложили все 150+ бизнес-сущностей — 240+ колонок с именами вроде string82 и numeric31, метаданные и данные вперемешку. Схему ведь больше «никогда не придётся менять».

В исходном orders.csv было 11 строк. До BI-витрины дошло 7, а валовая сумма 4720.30 после применения бизнес-правил превратилась в 2200.30 выручки. Четыре строки не исчезли: каждая попала в rejects с конкретной причиной.

На этом небольшом примере покажу весь путь данных через RAW, STG, CORE и MARTS. Разберём, где меняются строки и суммы, как пережить повторную доставку файла и какие проверки позволяют доверять итоговому дашборду. Внутри MinIO, Postgres и Airflow.

Недавно я реализовывал задачу автоматизации выставления счетов за оказание логистических услуг на основании данных из WMS и ТСД. В процессе разработки я использовал параметризованные SQL-запросы к базе данных. Это создает определенную сложность: для описания новых услуг или изменения логики расчета требуется менеджер, владеющий SQL, что на практике маловероятно. Чтобы снизить нагрузку на разработчика по сопровождению системы, я принял решение использовать технологии искусственного интеллекта.

Зашёл тут на карту и вижу странную картину. На Чистых прудах висят три пина ровно друг на друге. Тыкаю, а там один и тот же «Вишнёвый сад» в Ленкоме. Совпадает всё, вплоть до времени и зала. Просто данные прилетели из трёх разных мест. Где-то площадка записана просто как Ленком, где-то полностью с именем Марка Захарова, а в третьем случае вообще пусто. Для пользователя это три разных события на карте, хотя спектакль на самом деле один.

У меня сейчас Окрест тянет афиши по шестнадцати городам из Яндекс Афиши, Afisha.ru, Timepad, KudaGo и телеграм-каналов самих площадок. Сейчас в базе 23 097 активных событий, и пересечений между источниками много. 8260 событий приходят из двух источников, 533 из трёх, десять встречаются сразу в четырёх. На карте всё это должно превращаться в одну точку, а не в гирлянду пинов.

При разработке проектов на небольших VPS часто возникает ситуация, когда процесс mysqld загружает процессор на 100%. Обычно в такие моменты приходится заходить по SSH, открывать консоль бд и вручную вводить SHOW FULL PROCESSLIST;, чтобы найти тяжелый запрос и завершить его через KILL. Если запросов много, делать это вручную через стандартный вывод не всегда удобно.

Это легковесный интерактивный CLI - менеджер процессов, который работает на базе асинхронного драйвера aiomysql. Он опрашивает системную таблицу information_schema.processlist и выводит текущую активность в терминал в виде таблицы, позволяя управлять потоками СУБД.

В первой части статьи мы обсуждали, как обманчивая простота ActiveRecord приводит к проблеме N+1 запросов, и я предложила решение. После публикации и обсуждений я поняла: магия ActiveRecord оказалась ещё коварнее, чем я думала. В своём примере я упустила важнейший нюанс...

Цифры за закрытый месяц внезапно меняются, а поиск причины превращается в разбор всего пайплайна — от загрузки событий до логики витрин.

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

Как ускорить Hash Join в PostgreSQL, отбросив 99% строк ещё до самого соединения? Рассказываем о фильтре Блума в СУБД Tantor Postgres на живых и синтетических примерах.

Дорогие читатели, сегодня я расскажу о Pony ORM, которая во многих отношениях должна быть примером для других ORM: она дружественная к пользовалю, ведёт себя предсказуемо и, что немаловажно, имеет хорошую производительность. Речь пойдёт, в основном, не о фичах для пользователя (которых много и о которых можно узнать в этих видео 1, 2), а о внутренней архитектуре.