SQL *

Разбирая взаимоблокировки, Лоренс вспомнил, насколько опасным может быть использование SELECT FOR UPDATE при конкурентном доступе. В этом нет ничего нового, но Лоренс заметил, что многие не знают о режимах блокировки строк в PostgreSQL. Лоренс решил подробно описать, когда следует избегать SELECT FOR UPDATE.

Кругом только и разговоров о том, как бы заставить Postgres работать быстрее, эффективнее, и так далее. Но при этом никто даже не задумывается о том, как бы его замедлить. Само собой, о продуктивности и эффективности парятся в основном те, кому за это платят. Я не из из числа (можете это исправить -- дайте мне знать). На днях я работал над чуть более полезным руководством и в какой-то момент решил, что этому миру нужна такая конфигурация Postgres, которая будет выполнять запросы максимально медленно. Нахрена? Черт знает, но вот что у меня получилось.

Обычно SQL используют ради отчётов, аналитики и унылого «выгрузить за вчера». Но у языка запросов есть и другая, неожиданная сторона: если относиться к нему как к инструменту для сочинительства, можно попробовать написать рассказ. Сюжет, герои, диалоги — всё это вполне собирается на голом SQL. В статье я делюсь экспериментом, который начался ради шутки, а закончился странным ощущением, что база данных умеет рассказывать истории.

SQL я впервые выучил не ради красоты — нужен был для работы. Тогда казалось: язык скучный, служебный, без «души». SELECT, WHERE, JOIN… будто молоток или отвёртка. Но однажды, копаясь в старой демо-базе, я обратил внимание на то, что данные сами по себе напоминали короткие предложения. И пришла мысль: а что, если воспринимать таблицу не как набор строк, а как страницу романа?

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

Басня о коде и мёде

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

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

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

Так начинается наша история. История не только о коде, но и о вечных закономерностях природы, которые могут помочь нам создавать создавать красивые программы. Мы отправимся в самое сердце Шестиугольного Улья, откроем его секретный генетический код и узнаем, как выращивать собственных «рабочих пчел», которые будут служить нашему цифровому королевству добросовестно.

Сегодня мы рассмотрим достаточное простое решение, как ограничить доступ к любому вашему дашборду на Суперсете, зная лишь емейл или логин пользователя, без использования стандартных не самых удобных прав пользователя «зашитых» в Superset.

Месяц назад я опубликовал пост об инструменте для автоматической оптимизации SQL-запросов. Идея была простая — убрать этап «общения» с ИИ и предоставить простой интерфейс, где не нужно придумывать промпты.

За первый месяц сервис использовали более 1000 человек. Ниже — выводы и результаты.

В истории киберпреступности есть имена, которые знают все, и есть те, кто действовал в тени, но при этом оставил след в масштабах целых стран. Один из таких людей — Хьё Минь Нго, хакер из маленького вьетнамского города, который в юности умудрился получить доступ к личным данным почти двухсот миллионов граждан США. Его путь начался с банального подросткового любопытства к интернету и закончился международной охотой, громким арестом и тюремным сроком.

Привет, Хабр. Меня зовут Михаил Тимошкин. Я тимлид в команде Тематических каналов в Дзене.

Одна из классических головных болей при создании сервиса — синхронизация кода приложения со схемой БД. Есть много инструментов для управления изменениями схемы базы данных, таких как Liquibase или Flyway, для которых существуют плагины с кодогенерацией. Но что, если на проекте ничего подобного нет? Хорошая новость в том, что даже в такой ситуации можно найти эффективное решение! В этом мы убедились на собственном опыте при переходе с Hibernate на jOOQ.

В этой статье я расскажу, с какой проблемой мы столкнулись, какие решения рассматривали и что получили в итоге.

Порой, очевидные вещи таят в себе удивительные сюрпризы. Казалось бы, простые SQL конструкции: «IN» и «NOT IN». Что тут обсуждать-то?

Неважно почему, но иногда может появиться желание заняться рефакторингом ваших скриптов liquibase. В моём случае постоянно возникали конфликты в общем файле журнала изменений, количество скриптов превратилось в ужасно длинный список, а в самих скриптах невозможно было ориентироваться, поскольку они содержали по 1–2 команды, а в названии файла были только дата и действие. Долго это терпел, долго взвешивал плюсы и минусы, и всё время боролся с желанием всё отрефачить. И в какой-то момент дошёл до точки, когда желание взяло верх.

Решение принято: рефакторингу быть! Сразу скажу, приступать было страшно, но сейчас я очень доволен результатом. «Идеальную» структуру мы не получили, пришлось идти на компромиссы и заплатить свою цену, зато в новой структуре удалось вылечить все проблемы. Теперь в ней удобно ориентироваться и читать код, конфликты создаются очень редко, а все скрипты автоматически детектируются liquibase-ом. Но только это конец истории. А вначале было вообще непонятно, как рефакторить журнал изменений, да так, чтобы в существующие базы данных он смог пролиться, и ничего не поломал при этом!

Привет, Хабр! На связи Марк — ведущий архитектор группы компаний «ГлоуБайт». В этой статье я поделюсь результатами нагрузочного тестирования, которое мы с коллегами провели для сравнения Greenplum 6 с Greenplum 7 и Cloudberry.

Работая с Oracle Data Integrator (ODI), мы ценим его графический интерфейс за автоматизацию рутины и удобство разработки. Однако, когда проект масштабируется до десятков пакетов и сотен сущностей, GUI перестает быть оптимальным инструментом для отслеживания потоков данных, глубокого анализа и аудита зависимостей.

В таких случаях ключом к эффективности становится прямое взаимодействие с метаданными ODI через SQL‑запросы к его репозиториям. Эта статья посвящена именно этому — практической работе со структурой репозиториев ODI и детальному разбору SQL‑запроса для построения потоков данных.

Дисклеймер для тех, кто не смотрел «Друзей»

Моника Геллер — персонаж культового ситкома 90-х, безумно одержимая порядком. Её чек-листы для чек-листов, лейблы на лейблах и фетиш сортировки по цвету и размеру превратили её в мем про педантизм. Но именно Моника в сериале всегда вытаскивала друзей из провалов: когда нужно было за 3 часа организовать свадьбу, найти документы за 5 лет или просто понять, кто последний брал фондюшницу.

В реальной жизни мы живём не в квартире с purple дверью, но законы Моники работают лучше любого скрам-майнд-сета.

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

Сегодня разбираем COPY в PostgreSQL. Это рабочая лошадка для массовой загрузки и выгрузки данных.

Все мы любим SQLite. Это идеальный движок БД, компактная библиотека размером менее 1 МБ, быстрая, автономная и неубиваемая. Более того, это в принципе удобный способ хранения информации, поскольку СУБД выигрывает у файловой системы по скорости доступа, сжатию, функциональности полнотекстового поиска и т. д. Например, она вдвое быстрее файловой системы Ext4 под Linux.

SQLite — самая популярная в мире СУБД. Как рассказывалось в статье «Безумные и забавные факты о SQLite», в мире активно используется более триллиона (!) БД SQLite, это невероятное число. Просто она встроена во все смартфоны, браузеры, операционные системы и бесчисленное число других приложений.

Когда имеется несколько индексов с одинаковыми ведущими столбцами, иногда выбирается не лучший индекс, и время выполнения запроса увеличивается на порядки. Такие ситуации встречаются в сложных приложениях, но чаще всего в 1С:ERP, поскольку это приложение наиболее распространено. Как это обычно бывает: после миграции приложения на СУБД PostgreSQL часть запросов начинает выполняться медленнее. Планировщик выбирает индекс, созданный по меньшему числу столбцов, время выполнения увеличивается, потому что при использовании такого индекса индексные записи указывают на строки таблицы, которые не соответствуют условиям соединения. При выборе же индекса по большему числу задействованных в запросе столбцов время выполнения становится существенно ниже и практически не зависит от размера таблиц.

В статье детализируется часть доклада Максима Старкова на конференции PG BootCamp, которая прошла в апреле в Екатеринбурге. Описываются признаки таблиц и индексов, при работе с которыми может возникнуть проблема выбора худшего индекса, а также рассматривается пример, демонстрирующий, что строка "Buffers" характерна для определения эффективности выполнения запроса (в 18 версии PostgreSQL "Buffers" будет показываться в планах по умолчанию).

Как я пришел к написанию собственного пакета go, столкнувшись с отсутствием синтаксического сахара в языке и трудностях при разработке приложений в production с отсутствием команды инфраструктуры на go.

Привет! Меня зовут Яша Финкельберг, я senior аналитик в Авито. Здесь мы постоянно следим за удовлетворённостью продавцов и покупателей площадки и ищем способы улучшать их взаимодействие с Авито. Чтобы находить более детальные драйверы, сегментировать запросы и ставить предсказуемые цели в работе с обращениями, мы решили разработать собственную метрику для работы с опытом пользователей — weighted contact rate (wCR). В статье я расскажу, почему мы решили дополнить существующие метрики нашей, и дам пайплайн разработки, по которому уже вы сможете внедрить что-то подобное у себя в компании. Текст будет полезен аналитикам крупных компаний.

Шестая нормальная форма (6NF) играет ключевую роль в хранилищах данных (DWH), разбивая данные на мельчайшие части, привязанные ко времени фактического наступления событий и времени их регистрации в системе. 6NF легко адаптируется к изменениям в структуре данных без модификации существующих записей и снижает объем данных, которые необходимо обрабатывать при обновлениях и запросах.

Репозиторий на GitHub описывает лаконичный предметно-ориентированный язык (DSL) для битемпорального хранилища данных шестой нормальной формы (6NF) с первичными ключами UUIDv7, а также эквивалентный SQL-код для PostgreSQL 18 и EBNF. Программный код на этом DSL легко генерируется в Excel из метаданных.

Этот проект вдохновлен методологиями Anchor Modeling, Data Vault и Activity Schema.

DSL решает проблему работы с большими и сложными схемами данных 6NF, которые сложно визуализировать и поддерживать как с помощью традиционных инструментов моделирования, так и с использованием Anchor Modeler. Он также устраняет необходимость генерировать SQL-код с помощью Python или понимать запутанный код SQL Server, генерируемый Anchor Modeler.

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

У автора нет возможности разработать компилятор для данного DSL, и он рассчитывает на поддержку сообщества.

Английский вариант статьи

Сегодня памятная дата — прошло 25 лет с момента начала проекта Firebird.

Напомним как это начиналось. Многие кто работает с СУБД Firebird до 2000 года скорее всего использовали СУБД InterBase, из исходных кодов которого и появился Firebird. В 2000 году компания Borland приняла решение продолжить развитие InterBase как OpenSource продукт и открыла исходные коды своей СУБД, которой на тот момент пользовалось огромное количество программистов. Планировалось, что будет создана отдельная компания InterBase Software Corporation (ISC), которая будет заниматься развитием СУБД InterBase OpenSource отдельно от Borland, но в итоге от этой идеи отказались. Поэтому появился форк InterBase 6.0, а компания ISC переродилась в IBPhoenix. Символично название проекта — Феникс, восставший из пепла InterBase.

С 31 июля 2000 начинается история СУБД Firebird. И первое с чего начался проект это было исправление багов — версия InterBase 6.0.0.627 по количеству багов могла вполне считаться пре‑релизом. Теперь все исправления легли на плечи программистов Firebird. Поэтому первый релиз вышел только в 2001 году, до этого одной из альфа‑версий Firebird 0.95 достаточно активно пользовались.

Firebird был создан как форк InterBase и как это очень часто бывает тоже стал основой для другого форка. В конце 2001 года в результате объединения усилий группы российских разработчиков, использующих InterBase на Windows, на свет появился проект Yaffil.

После выхода Firebird 1.0 к участникам проекта пришло понимание, что дальше развивать проект на языке С будет не очень удобно и возникло решение переписать проект на С++. Firebird был переписан на C++ и под версией 1.5 вышел в 2004 году.