SQL *

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

…Если паттерны доступа существенно изменятся, то может потребоваться полная повторная обработка всех данных».

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

Представьте, что вам нужно найти иголку в стоге сена, но стог — это ваша БД, а иголка — данные со сложным шаблоном. Деофлтные операторы LIKE и IN тут не помогут — слишком уж они прямолинейны. Но зато здесь отлично зайдут регулярные выражения, которые позволяют выполнять сложные поиски и преобразования строк.

ORM были призваны восполнить пробел между объектно-ориентированными языками программирования, которые предоставляют разработчикам возможность работать с сущностями путем обращения к их интерфейсам, определяемым их чертежами (интерфейсы, классы, структуры), и процедурным подходом, реализуемым движками SQL-серверов. В некоторых случаях сюда же пытаются включить и адаптеры NoSQL хранилищ, вроде MongoDB, но конкретно с ней сильно проще, поскольку документ и так, в целом, предствляет из себя вполне себе сносно организованный объект с полями, маппинг которых в объекты языка программирования весьма тривиален, по сравнению с SQL.

Другая проблема, которую пришлось решать ORM в процессе решения первой — сформировать инструмент, который позволил бы составить правильный SQL-запрос в терминах языка программирования, при этом постараться не потерять в доступных "в сыром виде" средствах выражения на соответствующем SQL-серверу диалекте.

Продолжаем цикл статей по асинхронной SQLAlchemy в стиле ORM!

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

Что нас ждёт сегодня?

- Сессии и фабрики сессий: Узнаем, как эффективно управлять сессиями для взаимодействия с базой данных.

- Добавление данных в таблицы: Освоим безопасные методы добавления новых записей с использованием ORM-методов.

- Извлечение данных из таблиц: Погрузимся в мир извлечения данных. Рассмотрим простые запросы и более сложные фильтры для работы с данными.

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

Не пропустите, будет интересно и полезно!

Принимать сложные параметры запроса в виде JSON - полезно, хранить его в базе - удобно, но работа с ним в рамках SQL-запроса зачастую вызывает затруднения.

Сегодня столкнулся с очередным нетипичным вариантом использования - "перекладыванием" значений из JSON-строк в столбцы.

Давайте сделаем это попроще.

В базах данных нет серебряной пули, универсального рецепта. Мне захотелось проверить экспериментально один граничный случай использования in memory tables и natively compiled - когда в тесте все было хорошо, а на реальных данных начались тормоза.

Наконец-то пришло время взяться за то, что я давно планировал — подробный гайд по асинхронной версии SQLAlchemy 2.0 в стиле ORM. В этой серии статей я подробно расскажу обо всех аспектах: от создания моделей и установления связей между ними до миграций с Alembic и взаимодействия с данными в базе. Мы будем шаг за шагом разбирать ключевые моменты работы с асинхронной базой данных, что позволит вам глубже понять SQLAlchemy и применить эти знания на практике.

Для начала, давайте разберёмся, что такое SQLAlchemy и почему каждый разработчик, работающий с реляционными базами данных (такими как SQLite, PostgreSQL, MySQL и т. д.), должен знать о ней. После этого — настройка. Мы будем работать с PostgreSQL, но не переживайте: код, который мы напишем, универсален для всех реляционных баз данных. Мы начнем с базовой настройки SQLAlchemy для асинхронного взаимодействия, а затем перейдём к созданию таблиц в современном декларативном стиле.

В наше время цифровизация процессов и событий вокруг нас имеет всё большую и большую востребованность. По этой причине важно понимать не только плановые и фактические показатели, но также и динамику их изменений. В этой статье я расскажу, как мы реализовали систему мониторинга востребованности дашбордов. Разработчики называют это визуализацией над визуализацией. Под катом подробный рассказ с примером кода, так что все желающие смогут повторить подобное на своей BI системе, если вы также выбрали гибкую платформу для своих задач.

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

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

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

SQL кажется чем-то, что мы все хорошо знаем, и мало чем может удивить. (Ему уже 50 лет!) Возможно, пришло время пересмотреть подходы, так как мы уже прошли фазу хайпа по поводу NoSQL, и снова возвращаемся к “используйте просто Postgres”, а иногда и к “SQLite тут за глаза”.

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

Основной принцип многослойной архитектуры заключается в разделении критически важных частей кода (логики) от деталей реализации (например, SQL-запросов). Одним из способов достижения такого разделения является паттерн «Репозиторий». Однако, наиболее сложным аспектом такой архитектуры является обработка транзакций.

Недавно, на хабре вышла статья про один нюанс в оптимизаторе PostgreSQL [1]. Будучи предельно технической и скучной по-определению, она триггернула интересную дискуссию в комментах и дала мне, как разработчику систем баз данных, возможность взглянуть на систему с точки зрения разработчика приложений. Это оказалось крайне продуктивным и даже привело к патчу и треду в сообществе. Возможно, нам нужно больше таких небольших и узко-специализированных постов? Данная статья - попытка развить это направление.

[1] Странное поведение планировщика запросов PostgreSQL

Недавно попался на глаза запрос, которым хотели отобрать в таблице (очевидно, для последующего удаления) все id записей интервалов, которые полностью перекрыты каким-то другим интервалом того же owner'а.

Но self-JOIN показал себя не лучшим образом...

В мире управления базами данных от эффективного хранения больших объемов информации зависит оптимизация производительности и использования дискового пространства. В этой статье разберем основные методы сжатия данных в TOAST, их эволюцию, плюсы и минусы PGLZ и LZ4 и продемонстрируем базовую работу с TOAST в Postgres. В завершение обсудим, как данные с различными методами сжатия могут храниться в одной TOAST-таблице.

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

Сегодня я хотел бы поговорить подробнее о языке DAX, который активно применяется продвинутыми аналитиками во всем мире. Но я уверен, что сфера использования этого мощного инструмента охватывает не только суперпрофессионалов. Именно DAX делает аналитику доступнее для бизнес-пользователей, которые могут сделать сложные расчеты без познаний в программировании вообще. В этой статье мы рассмотрим три примера, в которых DAX помогает гораздо проще и быстрее решить типовые задачи, с которыми сталкиваются аналитики. Использовали ли Вы DAX раньше — неважно! Тех, кто впервые слышит о DAX, я постараюсь порадовать примерами, а опытных пользователей приглашаю к дискуссии.

В этой статье обсудим, что из себя представляет изолированность транзакций в БД, какие есть уровни изоляции транзакций, как их установить, какие бывают аномалии на разных уровнях, и что такое MVCC. Естественно, всё на простых примерах.

Некоторые головоломки можно решать на SQL just for fun, а часть получается выразить на этом декларативном языке даже эффективнее других, императивных.

Попробовать сделать более наглядное решение, а заодно познакомить с некоторыми нетривиальными возможностями PostgreSQL меня натолкнул пост о решении на Python задачи Black and White.

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

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

Поскольку язык DAX в рамках Power BI способен работать со множеством различных СУБД (например Oracle, MS SQL, MySQL, PostgreSQL, ClickHouse и т. д.), т. е. работает со множеством диалектов SQL, то в некотором смысле DAX является «надмножеством SQL» и приближается в этом смысле к реляционной алгебре. В данной статье приводится разбор типичного DAX для получения записи этого DAX в нотации реляционной алгебры. Интересующимся погружением в DAX и его реляционное представление — добро пожаловать :)

В одной из предыдущих статей я описывал проблемы, которые возникают при работе с временными таблицами. Тогда я вкратце описывал, почему нам приходится их так часто использовать. В частности, одной из причин была неправильная работа планировщика запросов в PostgreSQL. Многие из проблем планировщика запросов (и не только PostgreSQL) были также описаны в статье Почему не SQL. В этой статье я покажу достаточно простой и часто используемый случай, когда планировщик ошибается, что может приводить к значительному росту потребления ресурсов. 

Проблема воспроизводится на последней стабильной на данный момент версии PostgreSQL - 16.2. При этом используются стандартные настройки PostgreSQL. Я пробовал менять разные настройки, но мне не удалось добиться правильного плана в общем случае, поскольку в данном случае проблема скорее логическая, а не в определении стоимости вычислений. Однако, каждый может легко воспроизвести эту ситуацию локально и попробовать поиграться с настройками. 

Рассмотрим простую доменную логику, в которой есть документы и их строки. Для каждой строки вводится сумма. Строки лежат в отдельной таблице и ссылаются на документ :

Как мы ускорили запросы в Trino, научив оптимизатор удалять из плана лишние операторы Join.

Обсудим, почему в аналитических запросах часто возникают избыточные Join, почему это плохо для SQL-движков, какие эквивалентные преобразования позволяют избавиться от ненужных Join, и с какими проблемами мы столкнулись при интеграции данного функционала в наш форк Trino.

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

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

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

Сейчас мы активно ударились в создание инструментов для тестирования навыков в IT. Пока начали с одного — SQL. Нам помогли эксперты из Яндекс.Практикума: они подготовили тест, а мы собрали его и принесли вам. Надеемся, он поможет вам оценить знания и понять свой уровень. 

Если вы успешно пройдете тест, он будет красиво подсвечен в вашем профиле на Хабр Карьере — работодатели будут знать, что вы подтвердили свои знания.