次の方法で共有

クイック スタート: スキーマ エクスプローラーとデザイナーを使用する (プレビュー)

このクイック スタートでは、GitHub Copilot がコンテキスト対応の提案を使用してデータベース スキーマの設計、理解、および進化を行う開発者を支援する方法について説明します。 GitHub Copilot は、ゼロから構築する場合でも、既存のテーブルをリバース エンジニアリングする場合でも、SQL および ORM (Object-Relational Mapping) フレームワーク全体でプロセスを合理化し、スキーマの作業をより迅速かつスマートに、保守しやすくします。

このセクションでは、新しいスキーマを最初から作成する方法と、既存のデータベースを操作する方法の両方について説明します。 GitHub Copilot を使用して、コード優先のスキーマ定義の生成、オブジェクトの更新、または既存のデータベースのリバース エンジニアリングと探索を行うことができます。

スキーマの作成

  • ブログ アプリケーションの blog という名前の新しいスキーマを作成する SQL スクリプトを記述します。 スキーマには、 Posts、 Comments、 Usersの 3 つのテーブルが含まれている必要があります。 各テーブルには適切な主キーが必要であり、必要な外部キーのリレーションシップと制約を定義する必要があります。
  • LastModified型のdatetimeという名前の新しい列を、Posts スキーマのblog テーブルに追加します。 変更されたスキーマの完全な定義を含め、この変更を反映した更新された SQL スクリプトを生成します。
    • スキーマを作成する必要はありませんが、生成されたスクリプトを使用して実行して、生成されたコードの精度を検証できれば便利です。 次のセクションでは、 blogと呼ばれるこの新しいスキーマを引き続き使用します。
  • 現在のデータベースを使用して、ブログ アプリケーションの Prisma スキーマを生成します。 スキーマでは、 blog という名前の新しいデータベース スキーマを定義し、適切なリレーションシップと制約を持つ posts、 authors、および commentsのテーブルを含める必要があります。
  • Prisma移行を生成して、LastModified テーブルに datetime (Post) という列を追加します。
  • 現在のデータベースをリバース エンジニアリングし、CREATE TABLE スキーマ内のすべてのテーブルに対してSalesLTステートメントを生成します。
  • SalesLT.Product テーブルの構造を自然言語で要約します。
  • models.py テーブルの構造を反映するDjango (SalesLT.Customer) ファイルを生成します。
  • Entity Framework Core スキーマの SalesLT DbContext クラスとモデル クラスを生成します。
  • 適切な関連付けを使用して、 SalesLT.Product テーブルと SalesLT.Category テーブルの続編モデル定義を作成します。
  • 主キーフィールドやインデックス付きフィールドなど、TypeORM テーブルのSalesLT.Customer エンティティを生成します。
  • knex.js、SalesLT.SalesOrderHeader、およびOrderDate列を含むCustomerID テーブルを作成するTotalDue移行スクリプトを生成します。

リレーションシップを定義する

  • sql を記述して、Users スキーマ内のPostsとblogの間に一対多リレーションシップを定義します。 Postsの外部キーがUsers(UserId)を参照していることを確認します。
  • Categories スキーマにblog テーブルを追加し、Posts テーブルを更新して、Categories(CategoryId)を参照する null 許容外部キーを含めます。
  • Users列を含むようにRoleId テーブルを更新し、新しいRoles テーブルを作成する SQL を記述します。 外部キーリレーションシップを定義し、すべてのユーザーにロールが必要であることを強制します。
  • SalesLT.SalesOrderHeader テーブルを含むすべての外部キー リレーションシップを識別して記述します。
  • Posts スキーマのCategoriesとblogの間の外部キーを削除し、新しい結合テーブルを使用して多対多リレーションシップに置き換える SQL スクリプトを記述します。
  • Prisma、Customer、およびSalesOrderHeader間のSalesOrderDetail関係マッピングを記述します。
  • 続編モデルを更新して、hasManyとbelongsToの間のCustomerとOrderの関係を含めます。

スキーマの検証

  • ユーザー パスワードを格納するテーブルの制約を提案します (特殊文字や長さの制限など)。
  • NameのSalesLT.ProductCategory列がnvarchar(max)を使用せず、妥当な最大長の制約があることを確認します。
  • SalesLT.Address テーブルに主キーとすべての必須フィールドが定義されているかどうかを確認します。
  • sql スクリプトを生成して、 SalesLT スキーマ内のすべてのテーブルに CreatedDate 列または ModifiedDate 列が含まれるかどうかを検証します。
  • データベースに挿入する前に、 Customer テーブルの SQLAlchemy モデルを定義し、Pydantic またはカスタム Python 検証コントロールを使用して検証ロジックを含めます。
  • Data Annotations モデルにEntity Frameworkを追加して、EmailやPhoneNumberなどのフィールドが特定の形式に従っていることを確認します。

フィードバック: スキーマエクスプローラーとデザイナー

MSSQL 拡張機能の GitHub Copilot を改良および改善するために、次の GitHub 問題テンプレートを使用してフィードバックを送信します。 GitHub Copilot フィードバック

フィードバックを送信する場合は、次の内容を検討してください。

  • テスト済みのシナリオ – スキーマの作成、クエリの生成、セキュリティ、ローカライズなど、どの領域に重点を置いたかをお知らせください。

  • うまくいったこと - スムーズで役に立ち、期待を超えた経験について説明します。

  • 問題またはバグ – 問題、不整合、または混乱を招く動作を含めます。 スクリーンショットや画面の記録は特に役立ちます。

  • 改善の提案 – 使いやすさの向上、カバレッジの拡大、GitHub Copilot の応答の強化に関するアイデアを共有します。

関連コンテンツ