快速入门:使用 Schema 浏览器和设计器(预览版)

在本快速入门中,你将了解 GitHub Copilot 如何通过上下文感知建议帮助开发人员设计、理解和改进数据库架构。 无论是从头开始构建还是反向工程现有表,GitHub Copilot 都简化了跨 SQL 和 ORM(Object-Relational 映射)框架的过程,使架构工作更快、更智能、更易于维护。

本部分介绍从头开始创建新架构和使用现有数据库。 可以使用 GitHub Copilot 生成以代码为优先的模式定义、更新对象,或进行逆向工程和探索现有数据库。

架构创建

  • 编写 SQL 脚本以创建一个名为博客应用程序的新架构 blog 。 架构应包括三个表: PostsCommentsUsers。 每个表必须具有适当的主键,并且应定义必要的外键关系和约束。
  • 将一个名为 LastModified 类型的 datetime 新列添加到 Posts 架构中的 blog 表。 生成反映此更改的更新的 SQL 脚本,包括已修改架构的完整定义。
    • 无需创建架构,但如果可以使用生成的脚本并运行该脚本来验证生成的代码的准确性,则最好。 以下部分将继续使用此名为 blog 的新架构。
  • Prisma使用当前数据库为博客应用程序生成架构。 该模式应定义名为blog的新数据库架构,并包括postsauthorscomments的表,这些表应具有适当的关系和约束。
  • 生成Prisma迁移以在LastModified表中添加名为datetimePost)的列。
  • 反向设计当前数据库,并为架构中的所有CREATE TABLE表生成SalesLT语句。
  • 请用自然语言总结SalesLT.Product表的结构。
  • 生成反映models.py表结构的 DjangoSalesLT.Customer) 文件。
  • Entity Framework Core架构生成 DbContext 和模型类SalesLT
  • 为 `SalesLT.Product` 和 `SalesLT.Category` 表创建具有适当关联的 Sequelize 模型定义。
  • TypeORM表生成实体SalesLT.Customer,包括主键和索引字段。
  • 生成knex.js迁移脚本以创建包含SalesLT.SalesOrderHeaderOrderDateCustomerID列的TotalDue表。

定义关系

  • 编写 SQL 以在 Users 架构中定义 Postsblog 之间的一对多关系。 确保Posts中的外键引用Users(UserId)
  • Categories架构中添加blog表并更新Posts表以包含引用Categories(CategoryId)的可为空外键。
  • 编写 SQL 以更新 Users 表以包含 RoleId 列并创建新 Roles 表。 定义外键关系并强制要求每位用户都必须有一个角色。
  • 标识并描述涉及 SalesLT.SalesOrderHeader 表的所有外键关系。
  • 编写一个 SQL 脚本,该脚本在 Posts 架构中的 Categoriesblog 之间删除外键,并使用新的联接表将其替换为多对多关系。
  • PrismaCustomerSalesOrderHeader之间写入SalesOrderDetail关系映射。
  • 更新 Sequelize 模型以包含hasManybelongsTo之间的CustomerOrder关系。

架构验证

  • 建议存储用户密码的表的约束(例如,特殊字符和长度限制)。
  • 确认 Name 列中的 SalesLT.ProductCategory 未使用 nvarchar(max) ,并且具有合理的最大长度约束。
  • 请检查 SalesLT.Address 表是否定义了主键以及所有必填字段。
  • 生成 SQL 脚本以验证架构中的所有SalesLT表是否包括一个或多个CreatedDateModifiedDate列。
  • 定义一个用于 Customer 表的 SQLAlchemy 模型,并在插入数据库之前使用 Pydantic 或自定义 Python 验证器来进行验证逻辑。
  • Data Annotations模型中添加Entity Framework,以确保字段如EmailPhoneNumber遵循特定格式。

反馈:模式浏览器和设计器

为了帮助我们优化和改进 MSSQL 扩展的 GitHub Copilot,请使用以下 GitHub 问题模板提交反馈: GitHub Copilot 反馈

提交反馈时,请考虑包括:

  • 测试方案 – 告诉我们你关注哪些领域,例如架构创建、查询生成、安全性、本地化。

  • 效果良好 - 描述任何感觉流畅、有用或超出预期的体验。

  • 问题或漏洞 – 包括任何问题、不一致或令人困惑的行为。 屏幕截图或屏幕录制特别有用。

  • 改进建议 - 分享改进可用性、扩大覆盖范围或增强 GitHub Copilot 响应的想法。