Azure SQL | The .NET Blog

NL2SQL — это SQL-инъекция агентной эпохи

Emiliano Montesdeoca — Wed, 03 Jun 2026 00:00:00 +0000

Есть версия предложения NL2SQL, которая звучит идеально: пользователи задают вопросы на естественном языке, агенты генерируют SQL, данные возвращаются. Меньше экранов, меньше запросов, меньше кода. Просто.

Потом вы думаете об этом ещё пять минут.

Проблемы, о которых никто не говорит на демо

Схемы не были созданы для объяснения вещей. Криптические имена таблиц, непоследовательные имена столбцов, технически допустимые связи, которые семантически недопустимы без дополнительных предикатов — это нормально для корпоративных баз данных. Это не баги, это просто накопленная история бизнес-изменений. Но когда вы просите модель вывести намерение из схемы, которая не была создана для передачи намерения, модель попробует в любом случае. Она не сдастся. Она сгенерирует свой лучший вариант запроса и вернёт результаты с уверенностью.

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

Пользовательская проверка не масштабируется. “Просто проверяйте каждый запрос перед выполнением” звучит безопасно. Но это предполагает, что пользователи являются экспертами как в модели данных, так и в SQL — именно те люди, которым не нужен был интерфейс на естественном языке. Это также вводит когнитивную перегрузку и новый класс предвзятости подтверждения, где пользователи, перегруженные сложностью запроса, утверждают недействительные запросы вместо того, чтобы их исследовать.

И затем есть инъекция. В традиционной разработке SQL параметризация решала проблему инъекции, потому что пользовательский ввод заполнял параметры, а не структуру SQL. С NL2SQL модель сама генерирует SQL. Подсказка, контекст схемы, история разговора и полученные данные — всё влияет на то, что выполняется. Если кто-то создаёт подсказку, которая изменяет то, что генерирует модель, это инъекция — не на уровне параметра, а на уровне генерации запроса. И в отличие от удаления таблицы (очевидно, восстановимо), инъекция NL2SQL производит запросы, возвращающие неверные результаты без видимой ошибки. Бизнес-решения принимаются на основе неверных данных.

Что на самом деле решает SQL MCP Server

Именно здесь статья делает свой самый полезный практический вывод. Вместо того чтобы давать агенту произвольный доступ к схеме и надеяться на лучшее, SQL MCP Server предоставляет курируемую поверхность API, построенную на основе Data API builder.

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

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

Правильный вопрос

Статья не говорит “никогда не используйте NL2SQL.” Она говорит: будьте целенаправленны в том, где вы применяете его и что вы открываете. Для исследовательского анализа в контролируемой среде, с ограниченной схемой и доступом только для чтения, NL2SQL может подойти. Для производственных систем, где бизнес-решения зависят от результатов, курируемый уровень API значительно безопаснее.

Честность: некоторые проблемы действительно лучше решаются структурированными запросами за именованными конечными точками, чем естественным языком в SQL. SQL MCP Server даёт вам эту возможность, не отказываясь полностью от агентного интерфейса.

Оригинальная публикация: Considering NL2SQL? Should your database really be the prompt? How can SQL MCP Server help?

Azure SQL Теперь Может Генерировать Эмбеддинги — На Чистом T-SQL, Без Слоя Приложения

Emiliano Montesdeoca — Fri, 22 May 2026 00:00:00 +0000

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

Azure SQL только что устранил большую часть этого с двумя функциями, которые теперь стали общедоступными: CREATE EXTERNAL MODEL и AI_GENERATE_EMBEDDINGS.

Что Они Делают

Эти две функции T-SQL работают как интегрированный пайплайн:

CREATE EXTERNAL MODEL — регистрирует внешний эндпоинт модели ИИ как именованный объект базы данных. Вы устанавливаете расположение, формат API, тип модели и учётные данные один раз. Повторно используете везде.

AI_GENERATE_EMBEDDINGS — скалярная функция T-SQL, которая вызывает зарегистрированную модель и возвращает JSON-массив векторных значений. Работает в инструкциях SELECT, INSERT, UPDATE и MERGE.

Вместе они формируют сквозной пайплайн эмбеддингов без выхода из SQL-движка.

Полный Рабочий Процесс

-- Шаг 1: Зарегистрируйте провайдера эмбеддингов один раз
CREATE EXTERNAL MODEL MyEmbeddingModel
WITH (
 LOCATION = 'https://your-aoai-resource.openai.azure.com/',
 API_FORMAT = 'Azure OpenAI',
 MODEL_TYPE = EMBEDDINGS,
 MODEL = 'text-embedding-ada-002'
);

-- Шаг 2: Генерируйте эмбеддинги встроенно в T-SQL
UPDATE docs
SET embedding = AI_GENERATE_EMBEDDINGS(content USE MODEL MyEmbeddingModel)
FROM documents AS docs;

-- Шаг 3: Поиск с векторным расстоянием
SELECT TOP 10 id, content
FROM documents
ORDER BY VECTOR_DISTANCE('cosine', embedding,
 AI_GENERATE_EMBEDDINGS(@query USE MODEL MyEmbeddingModel));

Это весь пайплайн: данные в SQL, эмбеддинги генерируются в SQL, поиск по сходству в SQL. Без слоя оркестрации, без ETL, без отдельной векторной базы данных.

Поддерживаемые Форматы API и Параметры

В GA API_FORMAT поддерживает Azure OpenAI и OpenAI. MODEL_TYPE пока ограничен значением EMBEDDINGS. JSON PARAMETERS позволяет устанавливать значения по умолчанию на уровне модели, включая количество повторных попыток:

PARAMETERS = '{"sql_rest_options":{"retry_count":3}}'

Аутентификация использует учётные данные базы данных, поэтому секреты остаются вне кода приложения.

Что Это Открывает для Приложений .NET

Для разработчиков .NET, создающих функции ИИ на основе существующих данных SQL, это значительно. Вам не нужно:

Извлекать данные в промежуточное хранилище для эмбеддингов
Управлять внешним пайплайном эмбеддингов
Настраивать отдельную векторную базу данных (хотя можно использовать Azure AI Search для полнофункционального векторного хранилища)
Изменять слой доступа к данным приложения

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

Заключение

Паттерны RAG на SQL-данных стали значительно проще. AI_GENERATE_EMBEDDINGS + CREATE EXTERNAL MODEL означает, что ваше существующее SQL-приложение может получить возможности векторного поиска без добавления новой инфраструктуры.

Обе функции сегодня доступны в GA в Azure SQL Database и Azure SQL Managed Instance.

Оригинальная публикация: Generate Embeddings Function and External Model Object Support Are Now Generally Available in Azure SQL

Azure Data Studio прекратил работу: перенесите рабочий процесс Azure SQL в VS Code

Emiliano Montesdeoca — Sat, 09 May 2026 00:00:00 +0000

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

Azure Data Studio прекратил работу 6 февраля 2025 года, поддержка завершается 28 февраля 2026 года — рекомендуемая замена: VS Code с расширением MSSQL.

Что установить

Три вещи для начала:

Расширение MSSQL — найдите «SQL Server (mssql)» в Marketplace VS Code
Расширение SQL Database Projects — схема как код, валидация сборки, управляемая публикация
.NET 8 SDK — требуется системой сборки; отсутствующий SDK — самая частая проблема при первом запуске

Миграция подключений и настроек ADS

Расширение MSSQL включает ADS Migration Toolkit, который выполняет одноразовую миграцию в управляемом потоке: сохранённые подключения, группы подключений, настройки и сочетания клавиш импортируются автоматически.

Восстановление мышечной памяти F5

Пользователи ADS привыкли запускать запросы клавишей F5. Установите расширение MSSQL Database Management Keymap, чтобы вернуть сочетания клавиш в стиле ADS, включая F5.

SQL Database Projects: схема как код

Правая кнопка мыши на проекте → Опубликовать → настроить цель → просмотреть сгенерированный T-SQL-скрипт → развернуть. Предварительный просмотр скрипта перед развёртыванием — ключевая функция безопасности. Шаблоны элементов генерируют заготовки для таблиц, хранимых процедур и представлений — тот же рабочий процесс, что и в SSDT.

Частая проблема: несоответствие целевой платформы в файле .sqlproj вызовет ошибки сборки, если проект был создан для другой версии SQL Server.

Schema Compare и Schema Designer

Расширение также включает Schema Compare (сравнение проекта с развёрнутой базой данных) и Schema Designer (визуальное редактирование схемы без написания DDL вручную).

Разработчики Microsoft Fabric

Настройка идентична, но начните с портала Fabric и сначала подключите базу данных к Git, прежде чем открывать её в VS Code. У Microsoft есть специальное руководство: Azure Data Studio to VS Code — What it means for SQL database in Fabric developers.

Итог

Миграция — это одноразовый управляемый процесс, а не ручная пересборка. Установите три инструмента, запустите ADS Migration Toolkit, восстановите сочетания клавиш — и вернётесь к обычной работе менее чем за 10 минут.

Смотрите полную статью с пошаговыми скриншотами и инструкцией для Fabric.

SQL MCP Server на Azure App Service — без контейнеров

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

Этот пост переведён автоматически. Чтобы прочитать оригинал, нажмите здесь.

Честно говоря: каждый раз, когда в туториале вижу «требует контейнер», где-то внутри вздыхаю. Контейнеры великолепны — пока у вашей команды нет стратегии контейнеризации, и функция, казавшаяся простой, вдруг упирается в неожиданную оркестрационную сложность, которую никто не планировал.

Именно поэтому это привлекло моё внимание. SQL MCP Server теперь может работать на Azure App Service — без Docker, без Kubernetes, только с тем же конфигурационным файлом Data API Builder (DAB), который открывает ваш SQL-датабаз через MCP, REST и GraphQL.

Что такое SQL MCP Server?

Кратко для тех, кто ещё не знаком. SQL MCP Server располагается между вашим AI-агентом и SQL-базой данных. Вместо того чтобы давать агенту прямой доступ к базе данных (ужасная идея), он открывает ваши таблицы и представления как уровень абстракции — сущности с определёнными правами доступа.

Построен на Data API Builder, что означает: один конфигурационный файл управляет MCP и REST и GraphQL одновременно. Ваш агент общается с MCP-эндпоинтом. Традиционное приложение общается с REST или GraphQL. Одна конфигурация, одна среда выполнения, разные интерфейсы.

Это действительно удобно. Не нужно поддерживать два отдельных API-слоя.

Проблема контейнеров (и её решение)

Изначальная модель развёртывания SQL MCP Server использовала контейнеры. Это хорошо работает во многих командах — но не во всех. Многие .NET-команды стандартизировались на Azure App Service или виртуальных машинах. Требовать контейнерный runtime только ради одного SQL-эндпоинта — это лишнее трение, которого никто не просил.

Новое руководство показывает, как обойтись без контейнера вовсе. Всё работает через команду dab start, запущенный как стандартный .NET 8 веб-процесс на App Service.

# Установка Data API Builder
dotnet tool install microsoft.dataapibuilder --prerelease -g

# Инициализация конфигурации
dab init --database-type mssql --host-mode Development --connection-string "@env('SQL_CONNECTION_STRING')"

# Добавление сущности
dab add products --source dbo.products --permissions "authenticated:*"

# Настройка провайдера аутентификации App Service
dab configure --runtime.host.authentication.provider AppService

# Запуск сервера
dab start

На этом этапе у вас есть MCP по адресу /mcp, REST и GraphQL из того же процесса — и ничего в контейнере.

Аутентификация без общих API-ключей

Это та часть, которую я ценю больше всего. При развёртывании на App Service вы настраиваете Microsoft Entra ID в качестве провайдера аутентификации. Никаких общих секретов в конфигурационных файлах, никаких API-ключей для ротации.

Строка подключения хранится в переменных среды App Service (не в dab-config.json), а MCP-эндпоинт защищён платформенной аутентификацией. Если ваши Azure-нагрузки уже используют Entra ID, интеграция происходит органично.

Для локальной разработки переключайтесь в режим Simulator и STDIO-транспорт. Возвращайтесь к режиму AppService перед развёртыванием. Чисто и явно.

Развёртывание на App Service

az appservice plan create \
 --name <plan-name> \
 --resource-group <resource-group> \
 --sku B1 \
 --is-linux

az webapp create \
 --name <app-name> \
 --resource-group <resource-group> \
 --plan <plan-name> \
 --runtime "DOTNETCORE:8.0"

az webapp config set \
 --name <app-name> \
 --resource-group <resource-group> \
 --startup-file "dab start"

Затем разверните свой DAB-проект методом, который уже использует ваша команда. Ключевой момент: это развёртывание кода, а не контейнера.

Почему это важно для .NET-разработчиков

Если вы создаёте AI-агентов на .NET, рано или поздно им нужно будет работать с базой данных. SQL MCP Server предоставляет структурированный способ сделать это — без открытия сырых строк подключения или написания собственных API-слоёв.

Ознакомьтесь с полным руководством в оригинальной статье и примере на GitHub.

Итог

SQL MCP Server на App Service — практичный выбор для .NET-команд, которые хотят дать агентам структурированный доступ к SQL-данным без контейнерной стратегии. Попробуйте — ваши агенты оценят чистый API-интерфейс.

SQL Server 2025 как База Данных для Агентов: Безопасность, Бэкап и MCP в Одном Движке

Emiliano Montesdeoca — Sun, 26 Apr 2026 00:00:00 +0000

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

Я следил за серией Polyglot Tax Адитьи Бадрамраджу с большим интересом. Часть 4 завершает серию частями, которые реально определяют, доверяли бы вы этой архитектуре в продакшне.

Одна Модель Безопасности для Всех Моделей Данных

Одна политика Row-Level Security покрывает все таблицы — реляционные, JSON, граф, векторы. Одна политика, одно доказательство для аудитора.

Единый Бэкап = Атомарное Восстановление

В полиглотном стеке point-in-time recovery через пять баз данных — это кошмар согласованности. С одной базой данных восстановление атомарно по определению.

MCP-Интеграция: Агенты Без Middleware

SQL Server 2025 напрямую поддерживает SQL MCP Server. Агенты вызывают инструменты, движок автоматически обеспечивает изоляцию тенантов и маскировку столбцов.

Оригинальный пост Адитьи Бадрамраджу: The Polyglot Tax – Part 4.

SQL MCP Server — Правильный способ дать AI-агентам доступ к базе данных

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Этот пост был переведён автоматически. Оригинал можно прочитать здесь.

Давайте будем честны: большинство доступных сегодня MCP-серверов для баз данных устрашают. Они берут запрос на естественном языке, генерируют SQL на лету и выполняют его против ваших продакшн-данных. Что может пойти не так? (Всё. Абсолютно всё.)

Команда Azure SQL только что представила SQL MCP Server, и он использует принципиально другой подход. Построенный как функция Data API builder (DAB) 2.0, он даёт AI-агентам структурированный, детерминированный доступ к операциям с базой данных — без NL2SQL, без раскрытия вашей схемы и с полным RBAC на каждом шагу.

Почему не NL2SQL?

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

Вместо этого SQL MCP Server использует подход NL2DAB. Агент работает со слоем абстракции сущностей Data API builder и встроенным конструктором запросов для детерминированной генерации точного, хорошо сформированного T-SQL. Тот же результат для пользователя, но без риска галлюцинированных JOIN или случайного раскрытия данных.

Семь инструментов, а не семьсот

SQL MCP Server предоставляет ровно семь DML-инструментов, независимо от размера базы данных:

describe_entities — обнаружение доступных сущностей и операций
create_record — вставка строк
read_records — запрос таблиц и представлений
update_record — изменение строк
delete_record — удаление строк
execute_entity — выполнение хранимых процедур
aggregate_records — запросы агрегации

Это умно, потому что контекстные окна — это пространство для мышления агента. Наводнение их сотнями определений инструментов оставляет меньше места для рассуждений. Семь фиксированных инструментов держат агента сфокусированным на мышлении, а не на навигации.

Каждый инструмент можно включить или выключить отдельно:

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

Начало за три команды

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

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

История безопасности убедительна

Здесь зрелость Data API builder окупается:

RBAC на каждом уровне — каждая сущность определяет, какие роли могут читать, создавать, обновлять или удалять, и какие поля видны
Интеграция с Azure Key Vault — строки подключения и секреты управляются безопасно
Microsoft Entra + пользовательский OAuth — аутентификация продакшн-уровня
Content Security Policy — агенты взаимодействуют через контролируемый контракт, а не сырой SQL

Абстракция схемы особенно важна. Внутренние имена таблиц и столбцов никогда не раскрываются агенту. Вы определяете сущности, псевдонимы и описания, имеющие смысл для AI-взаимодействия — а не вашу ER-диаграмму.

Мульти-база и мульти-протокол

SQL MCP Server поддерживает Microsoft SQL, PostgreSQL, Azure Cosmos DB и MySQL. А поскольку это функция DAB, вы получаете REST, GraphQL и MCP эндпоинты одновременно из одной конфигурации. Те же определения сущностей, те же правила RBAC, та же безопасность — по всем трём протоколам.

Автоконфигурация в DAB 2.0 может даже проинспектировать вашу базу данных и динамически построить конфигурацию, если вам подходит меньше абстракции для быстрого прототипирования.

Моё мнение

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

Для .NET-разработчиков история интеграции чистая — DAB является .NET-инструментом, MCP Server работает как контейнер и интегрируется с Azure SQL, который большинство из нас уже использует. Если вы строите AI-агентов, которым нужен доступ к данным, начните здесь.

Подводя итоги

SQL MCP Server бесплатен, с открытым исходным кодом и работает где угодно. Это предписывающий подход Microsoft к предоставлению AI-агентам безопасного доступа к базам данных. Ознакомьтесь с полным постом и документацией для начала работы.