PostgreSQL *

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

Несмотря на избитость темы и многочисленные рекомендации избегать OR в выражениях WHERE/ON SQL запросов, жизнь вносит свои коррективы. Иногда сама постановка задачи подразумевает необходимость использовать OR. Я не собираюсь здесь рассматривать простые случаи, а сразу возьму быка за рога и рассмотрю случай, когда OR должно привести к двум разным выборкам по разным индексам одной и той же таблицы.

В эти предновогодние дни перегружать вас техническими деталями не будем. И даже не всё в этом выпуске будет вертеться вокруг СУБД и SQL. Начнём, впрочем, с такой серьёзной новости:

Postgres Pro Enterprise 16.1.1

Автоматизация процессов выглядит как задача без конца, не так ли?

Давайте подумаем, как можно упростить этот путь.

Существуют определенные стандарты программирования, которым нужно следовать разработчикам — зачем же они нужны?

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

Когда программное решение превращается в препятствие, вместо того чтобы быть инструментом, возникает вопрос – зачем оно вообще нужно?

В шедевральном мультфильме "Падал прошлогодний снег" строгая, но авторитетная жена послала мужика за ёлкой в лес. Главный герой же не особо сконцентрирован на основной цели своей предновогодней прогулки и отвлекался на все что только можно. Представим теперь, через 40 лет их дом попал под программу реновации, а они переехали почти в центр Москвы и живут теперь в башне типовой советской постройки. Отправила жена его, в этот раз со списком покупок к Новому году.

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

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

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

Триггеры On-Logon хорошо знакомы разработчикам приложений для СУБД Oracle Database.
On-Logon триггер является одним из видов триггеров событий базы данных, и автоматически срабатывает при подключении пользователя к БД.

В СУБД Postgres Pro Enterprise, еще в версии 14, среди прочих расширенных возможностей, была добавлена поддержка On-Logon триггеров.
В данной статье речь пойдет о данной функциональности, а также будет приведено сравнение с аналогичной функциональностью в СУБД Oracle Database.

Стоит отметить, что поддержка On-Logon триггеров будет добавлена в следующий мажорный релиз open source СУБД PostgreSQL - в версию 17.
Компания Postgres Pro передала свою реализацию этой технологии сообществу PostgreSQL.

Данный пример ярко характеризует модель развития СУБД PostgreSQL.
Идеи и их реализации, апробированные компаниями в коммерческих форках, передаются в open source. С другой стороны, компании точно также получают наработки open source в свой коммерческий форк.

Это формирует устойчивую ситуацию взаимовыгодного сотрудничества коммерческих компаний и open source сообщества. Эта ситуация может оказаться более долговечной, чем отдельные коммерческие компании или открытые продукты.

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

Если не видели дайджест за прошлый год — время наверстать упущенное!

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

Так у меня и родилась идея сделать одну полную инструкцию (прежде всего для себя), где в одном месте будет описан процесс деплоя. Если Вы читаете эту статью, значит мне удалось решить проблему «первой публикации приложения на сервер». К Вашему вниманию любимая рубрика «инструкция для чайников – как самостоятельно сделать свой первый деплой».

Дисклеймер:

Я классический вкатун с полного нуля; Java первый и на момент написания статьи единственный язык программирования, который я знаю; это моя первая статья; в этой статье нет рекламы; я не проходил платных курсов; у меня нет регулярного ментора.

У вас есть таблицы, либо ряд таблиц, строки которых нужно очистить и единственный способ, которым вы можете это сделать - это операция DELETE.

Помимо очевидной цели - очистки ненужных данных из таблицы, хотелось бы также увеличить свободное место в области диска, доступного для данных postgresql. Но при определенных условиях - операция DELETE не возвращает место, а операция UPDATE дополнительно его забирает.

Разбираем c Григорием Тарасенко, инженером команды SQL на примере, как реплицировать базы без использования слотов репликации.

Ноябрьский коммитфест принес немало интересного! Без лишних предисловий приступаем к обзору.

Самое интересное об июльском и сентябрьском коммитфестах ― в предыдущих статьях серии: 2023-07, 2023-09.

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

Сразу хочу отметить перед читателем, что это не просто вольные рассуждения на тему, а в том числе и презентация моей библиотеки для Python, которую можно найти на github и установить через pip, и которая трудится в моей многопользовательской игре как SQL движок проекта.

Проблемы ORM известны всем, кто хоть раз ими пользовался. Об этом существует множество статей как у нас, так и в зарубежных источниках. Эти проблемы в общем можно объединить довольно сложным термином Object‑relational impedance mismatch, что позволю себе вольно перевести как «Объектно‑реляционная разница потенциалов».

Альтернативой использованию ORM всегда было использование чистых драйверов баз данных и написание сырых SQL запросов, которые в свою очередь очень тяжело поддерживать и рефакторить в реальных проектах.

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

Группа Ленинград в их клипе про ЗОЖ преувеличивала последствия неумелого злоупотребления спортом в угоду зрелищности, но я согласен с ними что ко всему надо подходить с умом, без фанатизма. В Москве у меня есть друзья, которые покупают абонемент на фитнес и ходят туда не только первый и последний месяц его действия и не за пару недель до начала купального сезона.

Если вам важен спорт, то жить рядом с объектами спортивной инфраструктуры это не просто удобство, это основа здорового образа жизни.

За несколько лет Whoosh в несколько раз вырос по числу самокатов, пользователей и локаций, а данных по ним накопилось на 30 терабайт. Прежней архитектуры уже не хватало для работы. К тому же платить за I/O (input/output)-операции на Aurora (PostgreSQL) выходило дорого (тогда еще не было I/O‑optimized версии, однако с ее появлением, актуальность не исчезла). Другое дело — Redshift: расходы постоянны (n$/час), а работает он быстрее, благодаря колоночному формату хранения данных. В этом году мы переехали с одного хранилища на базе PostgreSQL — того, где вся отчётность для бизнеса и модели dbt — на рельсы Data Lake в AWS.

Меня зовут Никита Зеленский, я главный по данным в Whoosh. Эту статью я написал вместе с другими участниками переезда — Пашей Сивохиным, ГИС-аналитиком, и Костей Малыхиным, руководителем группы анализа данных. Надеюсь, наш опыт будет полезен всем, кому предстоит миграция данных, особенно если вы работаете с геоаналитикой.

В данной статье мы рассмотрим проектирование системы по подходу DB-first и то, какие проблемы он помогает не просто решить, а устранить как явление.

Продолжаю публикацию расширенных транскриптов лекционного курса "PostgreSQL для начинающих", подготовленного мной в рамках "Школы backend-разработчика" в "Тензоре".

Сегодня поговорим о самых простых, но важных, возможностях команды SELECT, наиболее часто используемой при работе с базами данных - формировании выборок (VALUES), их ограничении (LIMIT/OFFSET/FETCH), фильтрации (WHERE/HAVING), сортировке (ORDER BY), уникализации (DISTINCT) и группировке (GROUP BY).

Как обычно, для предпочитающих смотреть и слушать, а не читать - доступна видеозапись.

На просторах интернета заметил, что довольно мало статьей про ASP.NET под Linux. К сожалению, новички вроде меня копаются часами в поисках нужной информации, поэтому в этой статье мы вместе развернём минимальное приложение ASP.NET core под Linux в среде Ubuntu и в связке с PostgreSQL и с котиками на сервере nginx, а также упакуем всё в docker контейнеры. В ходе этой статьи мы разберём некоторые консольные команды для ежедневного пользования.

«PostgreSQL может заменить Kafka, RabbitMQ, MongoDB, Redis, Elasticsearch, Geospatial Database и даже Сron. Но есть нюансы».

В среду, 13 декабря, в прямом эфире встретились Senior Software Engineer в Avito Tech Виталий Лихачёв и DBA в Altinity Евгений Климов и обсудили PostgreSQL. В компании Виталия любят PostgreSQL, умеют его готовить и используют для множества задач. А вот в компании Евгения предпочитают Clickhouse и считают, что один инструмент для всего — не всегда хорошо. У экспертов получилась интересная и местами остренькая беседа.