Avertissement: ce qui suit ne convient que pour les petites tables (pensez <1000 lignes)
Voici une solution qui utilise le framework d'entité (pas SQL) pour supprimer les lignes, elle n'est donc pas spécifique à SQL Engine (R / DBM).
Cela suppose que vous effectuez cette opération pour des tests ou une situation similaire. Soit
- La quantité de données est petite ou
- La performance n'a pas d'importance
Appelez simplement:
VotingContext.Votes.RemoveRange(VotingContext.Votes);
En supposant ce contexte:
public class VotingContext : DbContext
{
public DbSet<Vote> Votes{get;set;}
public DbSet<Poll> Polls{get;set;}
public DbSet<Voter> Voters{get;set;}
public DbSet<Candidacy> Candidates{get;set;}
}
Pour un code plus ordonné, vous pouvez déclarer la méthode d'extension suivante:
public static class EntityExtensions
{
public static void Clear<T>(this DbSet<T> dbSet) where T : class
{
dbSet.RemoveRange(dbSet);
}
}
Ensuite, ce qui précède devient:
VotingContext.Votes.Clear();
VotingContext.Voters.Clear();
VotingContext.Candidacy.Clear();
VotingContext.Polls.Clear();
await VotingTestContext.SaveChangesAsync();
J'ai récemment utilisé cette approche pour nettoyer ma base de données de test pour chaque exécution de testcase (c'est évidemment plus rapide que de recréer la base de données à chaque fois, bien que je n'ai pas vérifié la forme des commandes de suppression qui ont été générées).
Pourquoi cela peut-il être lent?
- EF obtiendra TOUTES les lignes (VotingContext.Votes)
- puis utiliseront leurs identifiants (je ne sais pas exactement comment, peu importe), pour les supprimer.
Donc, si vous travaillez avec une quantité importante de données, vous tuerez le processus du serveur SQL (il consommera toute la mémoire) et la même chose pour le processus IIS car EF mettra en cache toutes les données de la même manière que le serveur SQL. N'utilisez pas celui-ci si votre table contient une quantité importante de données.
TRUNCATE
adeptes ne s'inquiète des contraintes liées aux clés étrangères.