Краткое руководство: используйте режим планирования для проектирования баз данных на основе спецификаций

Режим планирования — это функция Visual Studio Code, которая позволяет GitHub Copilot анализировать запрос, не внося никаких изменений. При проектировании базы данных режим планирования преобразует документ с требованиями к продукту, сформулированными на естественном языке (PRD), в обоснованную модель данных (таблицы, связи, связующие таблицы, направление внешнего ключа и ограничения) прежде чем написать хотя бы одну инструкцию CREATE TABLE. Затем вы перенастроите план в режим агента или конструктор схем для создания фактической схемы.

Tip

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

Основные итоги

  • В режиме плана создается письменный план (часто сохраненный как plan.md), который можно просмотреть перед выполнением.
  • Режим плана работает с учётом схемы при использовании вместе с участником чата @mssql или при прикреплении файлов с помощью #file:.
  • Используйте режим pair plan вместе с пользовательскими инструкциями, чтобы план автоматически наследовал ваши соглашения Transact-SQL (T-SQL).
  • Режим плана — это функция Visual Studio Code, а не конкретная для MSSQL, но она хорошо подходит для разработки базы данных.

Prerequisites

  • Visual Studio Code с установленным расширением MSSQL.
  • Активная подписка GitHub Copilot с режимом плана, доступным в раскрывающемся списке режима чата.
  • Папка рабочей области, в которой можно создать requirements.md файл.
  • Необязательно: целевое подключение к базе данных для передачи в режиме агента.
  • Необязательный: файл с пользовательскими инструкциями для ваших соглашений T-SQL.

Что такое режим плана?

Режим плана — это один из режимов чата в Visual Studio Code, а также режим запросов, режим редактирования и режим агента. В режиме плана, GitHub Copilot:

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

Затем можно перейти в режим агента (или конструктор схем) для выполнения плана. Общие сведения о режимах чата см. в Visual Studio Code.

Почему режим плана подходит для проектирования базы данных

Решения, связанные с моделью данных, накапливают последствия. Связующие таблицы, направление связей по внешним ключам, аудитные столбцы и варианты нормализации проще пересмотреть в плане в Markdown, чем в опубликованном DDL-коде. Режим плана позволяет:

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

Сквозной сценарий: схема TaskManager

В этом кратком руководстве показан полный процесс: PRD на естественном языке → план в Markdown → таблицы, созданные в конструкторе схем Schema Designer.

Шаг 1. Создание документа о требованиях к продукту

Создайте requirements.md в корне рабочей области. Описание приложения на естественном языке, включая сущности домена, связи и бизнес-правила. Сохраняйте фокус документа на продукте. Не указывайте типы столбцов или ограничения (это то, для чего предназначен файл пользовательских инструкций ).

# TaskManager - Product Specification

## Overview
A task management application for small development teams. Supports user
registration, role-based project membership, task tracking with multi-assignee
support, and team collaboration.

## User management
- Users register with email, username, first and last name, hashed password.
- Email and username must be unique across the system.
- Users can be deactivated (soft delete) rather than removed.
- A user can belong to multiple projects, each with a role: owner, admin, or member.

## Project management
- Projects have a name, description, and active/inactive status.
- Each project tracks who created it.
- Project membership is role-based - one entry per user per project.

## Task tracking
- Tasks belong to exactly one project.
- Required: title. Optional: description, due date.
- Status must be one of: todo, in-progress, done.
- Priority must be one of: low, medium, high, critical.
- Tasks can be assigned to multiple team members.

## Collaboration
- Team members can comment on tasks.
- Comments are text-based, tied to both a task and the author.

## Data integrity
- Every record must track when it was created and last updated.
- All relationships must enforce referential integrity.
- Deletes should be restricted (no orphan records).
- Status and priority fields must only accept valid values.

Шаг 2: Переключите GitHub Copilot Chat в режим планирования

  1. Откройте представление GitHub Copilot Chat.
  2. В раскрывающемся списке режима чата выберите "План".

Шаг 3. Отправка PRD в режим плана

Вложите requirements.md как контекст, перетащив файл в входные данные чата, используя #file:requirements.mdили нажав кнопку присоединения.

Based on the requirements document, think through the full data model:
identify all tables, relationships, junction tables, and constraints.
Save the plan so I can use it in the next step.

GitHub Copilot создает обоснованный план и сохраняет его как plan.md в рабочей области. План обычно включает в себя:

  • Список таблиц с их целью
  • Связи («один ко многим», «многие ко многим») и связующие таблицы для их реализации
  • Ограничения (уникальности, проверки, внешнего ключа), которые обеспечивают соблюдение бизнес-правил, описанных в PRD
  • Открытые вопросы или предположения, на которые опирается план

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

Шаг 4. Передача плана в режим агента или конструктор схем

После правильного чтения плана перейдите в режим агента и создайте схему.

  1. В раскрывающемся списке режима чата выберите агент.
  2. Отправьте запрос, ссылающийся на файл плана и целевую область:
Based on #file:plan.md, use Schema Designer to create all the tables
and relationships in my database. Focus on the database schema only -
skip any application layer items from the plan.

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

Tips

  • Свяжите с пользовательскими инструкциями. План автоматически наследует ваши соглашения, если у вас есть файл пользовательских инструкций для **/*.sql.
  • Сосредоточьте PRD на продукте. Избегайте указания типов столбцов или ограничений в requirements.md. Пусть план заполнит их в соответствии с вашими соглашениями.
  • Дорабатывайте план, а не DDL. Это дешевле пересмотреть план Markdown, чем удалить и воссоздать таблицы.
  • Сохраните план в системе контроля версий. План является ценным документом для будущих участников и для пересмотра решений по проектированию.
  • Используйте диаграммы Mermaid в PRD. ER-диаграммы в Mermaid помогают режиму планирования точно извлекать связи между сущностями.

Оставьте свой отзыв

Чтобы помочь нам уточнить и улучшить GitHub Copilot для расширения MSSQL, используйте следующий шаблон проблемы GitHub для отправки отзывов: GitHub Copilot Feedback

При отправке отзывов рассмотрите возможность включения:

  • Тестируемые сценарии: сообщите нам, на какие области вы ориентированы, например создание схемы, создание запросов, безопасность, локализация.

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

  • Проблемы или ошибки: любые проблемы, несоответствия или запутанное поведение. Снимки экрана или записи экрана особенно полезны.

  • Предложения по улучшению: поделитесь идеями для улучшения удобства использования, расширения охвата или улучшения ответов GitHub Copilot.

Связанный контент

  • Last updated on