Partager via

Démarrage rapide : Utiliser l’Explorateur de schémas et le concepteur (Aperçu)

Dans ce guide de démarrage rapide, vous allez découvrir comment GitHub Copilot aide les développeurs à concevoir, comprendre et évoluer des schémas de base de données avec des suggestions contextuelles. Que vous construisiez à partir de zéro ou que vous fassiez de l'ingénierie inverse sur des tables existantes, GitHub Copilot simplifie le processus dans les cadres SQL et ORM (Object-Relational mappage), ce qui rend le travail sur le schéma plus rapide, plus intelligent et plus facile à gérer.

Cette section traite de la création de schémas à partir de zéro et de l’utilisation de bases de données existantes. Vous pouvez utiliser GitHub Copilot pour générer des définitions de schéma axées sur le code, mettre à jour des objets, faire de l'ingénierie inverse et explorer les bases de données existantes.

Création de schéma

  • Écrivez un script SQL pour créer un schéma nommé blog pour une application de blog. Le schéma doit inclure trois tables : Posts, Commentset Users. Chaque table doit avoir des clés primaires appropriées, et les relations et contraintes de clé étrangère nécessaires doivent être définies.
  • Ajoutez une nouvelle colonne nommée LastModified de type datetime à la Posts table dans le blog schéma. Générez le script SQL mis à jour reflétant cette modification, y compris la définition complète du schéma modifié.
    • Il n’est pas nécessaire de créer le schéma, mais il serait utile d’utiliser le script généré et de l’exécuter pour valider la précision du code généré. La section suivante continue d’utiliser ce nouveau schéma appelé blog.
  • Générez un Prisma schéma pour une application de blog à l’aide de ma base de données actuelle. Le schéma doit définir un nouveau schéma de base de données nommé blog et inclure des tables pour posts, authorset , avec commentsdes relations et des contraintes appropriées.
  • Générez une Prisma migration pour ajouter une colonne appelée LastModified (datetime) à la Post table.
  • Effectuez la rétroconception de la base de données actuelle et générez des instructions CREATE TABLE pour toutes les tables dans le schéma SalesLT.
  • Résumez la structure de la SalesLT.Product table en langage naturel.
  • Générez un models.py fichier (Django) qui reflète la structure de la SalesLT.Customer table.
  • Générez une Entity Framework Core classe DbContext et des classes de modèle pour le SalesLT schéma.
  • Créez une définition de modèle Sequelize pour les tables SalesLT.Product et SalesLT.Category avec des associations appropriées.
  • Générez une TypeORM entité pour la SalesLT.Customer table, y compris la clé primaire et les champs indexés.
  • Générez un knex.js script de migration pour créer la table SalesLT.SalesOrderHeader avec les colonnes OrderDate, CustomerID et TotalDue.

Définir des relations

  • Écrivez SQL pour définir une relation un-à-plusieurs entre Users et Posts dans le blog schéma. Vérifiez que la clé étrangère dans Posts fait référence à Users(UserId).
  • Ajoutez une table au schéma Categories et mettez à jour la table blog pour inclure une clé étrangère nullable référencant Posts.
  • Écrivez SQL pour mettre à jour la Users table pour inclure une RoleId colonne et créer une Roles table. Définissez une relation de clé étrangère et appliquez que chaque utilisateur doit avoir un rôle.
  • Identifiez et décrivez toutes les relations de clé étrangère qui impliquent la SalesLT.SalesOrderHeader table.
  • Écrivez un script SQL qui supprime une clé étrangère entre Posts et Categories dans le blog schéma et le remplace par une relation plusieurs-à-plusieurs à l’aide d’une nouvelle table de jointure.
  • Écrire Prisma des mappages de relations entre Customer, SalesOrderHeader et SalesOrderDetail.
  • Mettez à jour un modèle Sequelize pour inclure une relation entre hasMany et belongsTo ainsi qu'entre Customer et Order.

Validation du schéma

  • Suggérer des contraintes pour une table stockant des mots de passe utilisateur (par exemple, des caractères spéciaux et des limites de longueur).
  • Vérifiez que la Name colonne dans SalesLT.ProductCategory n’utilise nvarchar(max) pas et a une contrainte de longueur maximale raisonnable.
  • Vérifiez si la SalesLT.Address table a une clé primaire et tous les champs requis définis.
  • Générez un script SQL pour vérifier que toutes les tables du schéma SalesLT incluent une colonne CreatedDate ou une colonne ModifiedDate.
  • Définissez un modèle SQLAlchemy pour la Customer table et incluez la logique de validation à l’aide de validateurs Python Pydantic ou personnalisés avant l’insertion dans la base de données.
  • Ajoutez Data Annotations dans un modèle Entity Framework pour vous assurer que des champs comme Email et PhoneNumber respectent des formats spécifiques.

Commentaires : Explorateur de schémas & Concepteur

Pour nous aider à affiner et améliorer GitHub Copilot pour l’extension MSSQL, utilisez le modèle de problème GitHub suivant pour envoyer vos commentaires : Commentaires GitHub Copilot

Lors de l’envoi de commentaires, envisagez d’inclure :

  • Scénarios testés : informez-nous des domaines sur lesquels vous vous êtes concentré, par exemple, la création de schéma, la génération de requêtes, la sécurité, la localisation.

  • Ce qui a bien fonctionné – Décrivez toutes les expériences qui semblaient fluides, utiles ou ont dépassé vos attentes.

  • Problèmes ou bogues : incluez des problèmes, des incohérences ou des comportements déroutants. Les captures d’écran ou les enregistrements d’écran sont particulièrement utiles.

  • Suggestions d’amélioration : partagez des idées pour améliorer la facilité d’utilisation, développer la couverture ou améliorer les réponses de GitHub Copilot.

Contenu connexe