Как я создаю среду блокнотов для SQL внутри клиента баз данных

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


Создание запросов часто требует копирования результатов в новые запросы или экспорта данных в CSV для визуализации. Документируя анализ, можно допустить ошибки при вставке SQL в документы.

Чтобы избежать этих неудобств, я интегрирую блокноты в Tabularis — среду анализа SQL на основе ячеек внутри клиента базы данных. Это работа без Jupyter и Python runtime, только SQL и markdown ячейки, встроенные диаграммы и функции, которые упрощают многозапросный анализ.

Разработка ещё продолжается, но ядро уже работает. Вот как это выглядит и как развивается.

Как это работает

Блокнот — это последовательность ячеек: SQL или markdown. SQL-ячейки выполняются непосредственно против вашей базы данных и отображают результаты в интерфейсе с сеткой данных, соответствующей редактору запросов: сортировка, фильтрация, изменяемые панели. Ячейки markdown создаются для добавления документации между запросами.

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

Ссылки на ячейки через CTE

Это та часть, которая меня больше всего воодушевляет.

Любая SQL-ячейка может ссылаться на запрос другой ячейки с помощью {{cell_N}}. Во время выполнения это разрешается как CTE (общее табличное выражение, Common Table Expression):

-- Ячейка 1: Базовый запрос
SELECT customer_id, SUM(amount) AS total
FROM orders
GROUP BY customer_id
-- Ячейка 3: Ссылается на ячейку 1
SELECT * FROM {{ cell_1 }}
WHERE total > 1000

Превращается в:

WITH cell_1 AS ( SELECT customer_id, SUM(amount) AS total FROM orders GROUP BY customer_id
)
SELECT * FROM cell_1
WHERE total > 1000

Никаких временных таблиц, никакого копирования и вставки. Измените базовый запрос, перезапустите зависимые ячейки — всё остаётся синхронизированным. Можно выстраивать цепочки из нескольких ячеек, и каждый промежуточный результат остаётся видимым.

Встроенные диаграммы и параметры

Любой результат с двумя и более столбцами и хотя бы одной строкой можно визуализировать в виде диаграммы — столбчатой, линейной или круговой — прямо в ячейке. Просто выберите столбец меток и столбцы значений — и всё готово. Конфигурация сохраняется вместе с ячейкой.

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

Параметры работают по той же логике «определи один раз, используй везде»:

@start_date = '2024-01-01'
@end_date = '2024-12-31'
@min_amount = 500

Каждая SQL-ячейка включает значение с параметром @start_date, подставляемое перед выполнением. Если изменить его, все запросы обновятся автоматически. Это удобно для ежемесячных отчётов, когда логика остаётся неизменной, а входные данные подлежат изменению.

Параллельное выполнение и управление запусками

Не все ячейки зависят от предыдущих. Независимые ячейки обозначаются специальным значком, что позволяет одновременно выполнять их в процессе запуска "Run All", вместо последовательного выполнения.

Сочетание Ctrl+Shift+Enter запускает все SQL-ячейки подряд. Опция "Stop on Error" управляет поведением выполнения при ошибках, позволяя либо остановить процесс, либо продолжить выполнение. После завершения работы выводится сводная карточка с количеством успешных, неудачных и пропущенных ячеек; нажав на неудачную ячейку, можно быстро к ней перейти.

Каждая SQL-ячейка может обращаться к другому подключению к базе данных. Получайте данные из production PostgreSQL в одной ячейке, сравнивайте с аналитическим SQLite в следующей. Работает с MySQL, MariaDB, PostgreSQL и SQLite.

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

История выполнения и помощь ИИ

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

Каждая SQL-ячейка имеет кнопки AI и Explain — опишите, что вы хотите, получите SQL в ответ, или разберите существующий запрос. Есть также функция автоименования: нажмите на значок искр, и ИИ сгенерирует имя ячейки на основе её содержимого. Именованные ячейки отображаются в структуре блокнота для навигации.

Для меня это особенно важно в длинных исследовательских сессиях, где один и тот же запрос меняется пять или шесть раз подряд. История позволяет сравнить не только текст SQL, но и побочные эффекты: сколько строк вернулось, сколько времени заняло выполнение, на каком шаге появились расхождения. Это уменьшает соблазн сохранять промежуточные версии в отдельных файлах или заметках и делает сам блокнот самодостаточным рабочим журналом.

Организация, импорт и экспорт

Для навигации по большим блокнотам предусмотрено несколько инструментов:

  • Сворачивание ячеек для отображения только заголовков
  • Перетаскивание для изменения порядка
  • Имена ячеек (ручные или сгенерированные ИИ) для идентификации
  • Ячейки markdown в качестве разделителей секций

Форматы обмена данными:

  • .tabularis-notebook — JSON с ячейками, параметрами, диаграммами, без данных результатов; поделитесь им, импортируйте, подключитесь к другой БД, запустите
  • Экспорт в HTML — самодостаточный документ с отрендеренным markdown, подсветкой синтаксиса, встроенными таблицами результатов, тёмная тема
  • Отдельные результаты экспортируются как CSV или JSON

Именно разделение структуры и данных делает формат переносимым. Один коллега может собрать блокнот на staging-базе, другой импортирует его у себя и запускает на production-read replica, не получая вместе с файлом чувствительные результаты выборок. Для аналитических команд это удобнее, чем пересылать набор отдельных SQL-файлов и отдельно объяснять порядок запуска.

Что ещё не готово

Честно о шероховатостях, которые я планирую устранить в ближайших итерациях:

  • Большие блокноты (30+ ячеек) нуждаются в лучшей виртуализации
  • Обнаружение циклических ссылок отсутствует — нужен граф зависимостей
  • Настройка диаграмм минимальна: нет меток осей, нет цветовых палитр
  • Навигация с клавиатуры между ячейками реализована частично
  • Отмена/повтор действий на уровне блокнота ещё не существует (на уровне ячейки работает через Monaco)

Я специально оставляю эти ограничения явными, потому что от них зависит сценарий использования. Если вам нужен polished BI-dashboard, инструмент ещё сырой. Если нужен рабочий ноутбук для SQL-анализа, где важнее быстро собрать запросы, параметризовать их и получить переносимый артефакт, даже текущая версия уже даёт практическую ценность.

Зачем это строить?

Клиенты баз данных по-настоящему не эволюционировали дальше схемы «подключись, запроси, посмотри таблицу». Инструменты анализа двигались вперёд — Jupyter, Observable, dbt — но клиент БД оставался позади.

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

Это не замена Jupyter. Никакого Python, никакого R. Tabularis создан специально для SQL и для той работы, которую большинство людей реально выполняет со своей базой данных каждый день: специальное исследование, построение отчётов, валидация данных, исследование производительности. Этот фокус — намеренное решение, а не ограничение.

Ответы на эти вопросы могут быть для вас полезными

Чем ссылки на ячейки через CTE отличаются от обычных подзапросов? Ссылки через {{cell_N}} разворачиваются в CTE автоматически при выполнении. Вам не нужно вручную копировать SQL из одной ячейки в другую — достаточно изменить базовый запрос, и все зависимые ячейки получат обновлённый результат при следующем запуске.

Можно ли использовать Tabularis с несколькими базами данных одновременно? Да. Каждая SQL-ячейка может обращаться к отдельному подключению. Поддерживаются MySQL, MariaDB, PostgreSQL и SQLite — можно сравнивать данные из разных источников в рамках одного блокнота.

Как параметры помогают при работе с повторяющимися отчётами? Параметры вроде @start_date или @min_amount определяются один раз и подставляются во все SQL-ячейки перед выполнением. Для ежемесячных отчётов достаточно изменить одно значение и нажать «Run All» — логика запросов остаётся нетронутой.

Что происходит с данными при экспорте блокнота? Файл .tabularis-notebook содержит только структуру: ячейки, параметры и конфигурацию диаграмм. Данные результатов не сохраняются. Это позволяет безопасно делиться блокнотом с коллегами — они подключают свою БД и запускают его самостоятельно.

Подходит ли инструмент для командной работы или это сугубо личный инструмент? На текущем этапе Tabularis ориентирован на индивидуальный рабочий процесс, но формат .tabularis-notebook изначально проектировался как переносимый: поделитесь файлом, коллега импортирует его, подключается к нужной БД и воспроизводит весь анализ.

Оцените статью
0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
0
Оставьте комментарий! Напишите, что думаете по поводу статьи.x