IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Développement SQL Server Discussion :

DELETE qui ignore les erreurs


Sujet :

Développement SQL Server

  1. #1
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    10 005
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 005
    Points : 27 346
    Points
    27 346
    Par défaut DELETE qui ignore les erreurs
    Bonjour à tous.

    Je dois préparer un script de purge partielle d'une base de données. La base comporte près de 300 tables, certaines des tables peuvent dépasser les 10 millions d'enregistrements. Le but est de supprimer toute une partie de l'activité dans la base, typiquement, ça pourrait être, par exemple, toute l'activité d'un département dans une entreprise car le département en question est dissout ou vendu, etc...
    L'ensemble des 300 tables sera donc impacté, à priori !

    J'ai certaines tables qui sont référencées par plus d'une centaine de clés étrangères, dont les données peuvent être référencées par des enregistrements qui vont être supprimés (donc théoriquement à supprimer), mais qui peuvent être, en même temps, référencées par des enregistrements qui ne seront pas supprimés.
    C'est typiquement le cas d'une table annuaire qui regrouperait les infos de toutes les personnes physiques ou morales utilisées ailleurs dans la base.


    Est-ce qu'il y a moyen de construire une requête DELETE qui, sur le principe, supprimerait les enregistrements qu'elle peut supprimer, non référencés donc, et qui, pour les enregistrements qui ne peuvent pas être supprimés
    - ne génère pas d'erreur ou d'exception
    - n'arrête pas ou ne fait pas planter le script dans lequel elle sera
    - ignore l'enregistrement non supprimable
    - passe à l'enregistrement suivant pour tenter de le supprimer

    L'analyse n'est pas terminée, mais un certain nombre de tables sera concerné par ce type de requête
    Ces requêtes seront dans un script plus complet qui fera la purge partielle de la totalité des tables
    La totalité des purges sera, normalement sous couvert d'une transaction
    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

  2. #2
    Expert éminent sénior
    Homme Profil pro
    Responsable Données
    Inscrit en
    janvier 2009
    Messages
    4 880
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Responsable Données

    Informations forums :
    Inscription : janvier 2009
    Messages : 4 880
    Points : 11 808
    Points
    11 808
    Par défaut
    Bonjour,
    Au départ j'aurai parlé d'une simple requête avec des "WHERE NOT EXISTS", mais avec des centaines de clé étrangères c'est pas gagné.
    Tu peux peut-être la générer via du code en "tapant" dans les tables sys.tables, sys.foreign_keys et sys.foreign_key_columns.

    Autre solution (mais j'ai un petit doute): créer une vue qui ne renvoie que ce qui peut être supprimé, et lancer la suppression sur cette vue.

    Mais je me demande ce que va en penser Sql Serveur, et ce que ça va donner niveau perf.

    Tatayo.

  3. #3
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    10 005
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 005
    Points : 27 346
    Points
    27 346
    Par défaut
    Oui, ça risque de pas être si simple que ça.

    En continuant mon analyse, je me rends compte que je ne vais sans doute pas pouvoir m'appuyer uniquement sur une approche pure SQL, mais que je vais devoir aussi y intégrer une approche métier.

    J'ai déjà trouvé le cas d'une table qui s'auto-référence directement, j'en ai une autre qui s'auto-référence par l'intermédiaire d'une table association.

    Je vais sans doute aussi avoir des cas ou un enregistrement père ayant des fils ne serait théoriquement pas supprimable, sauf que, en ne tenant pas compte de certains fils, il le deviendrait et ces fils-là serait du coup aussi supprimable.
    Là, on est clairement sur du métier, plus sur du sql pur. Et du coup je pense que je vais pouvoir abandonner tout espoir d'une automatisation de la génération des scripts de suppression.


    Mais l'idée du DELETE sans erreur va rester valable malgré tout pour certaines tables.
    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

  4. #4
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    8 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 8 612
    Points : 31 260
    Points
    31 260
    Billets dans le blog
    2
    Par défaut
    Une centaine de clefs étrangères dans une même table est symptomatique d'un très gros problème de modélisation

    Cela étant dit, si les colonnes FK font l'objet d'une clause ON DELETE CASCADE, le ménage sera fait automatiquement par le SGBD, mais ça peut être long si la profondeur de la cascade est importante

  5. #5
    Expert éminent sénior
    Homme Profil pro
    Responsable Données
    Inscrit en
    janvier 2009
    Messages
    4 880
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Responsable Données

    Informations forums :
    Inscription : janvier 2009
    Messages : 4 880
    Points : 11 808
    Points
    11 808
    Par défaut
    Citation Envoyé par escartefigue Voir le message
    Une centaine de clefs étrangères dans une même table est symptomatique d'un très gros problème de modélisation
    J'avais traduit sa phrase d'une autre façon: une centaines de clé étrangères qui "pointent" vers la même table.

    Mais dans les deux cas je me demande bien comment on peut en arriver là.

    Tatayo.

  6. #6
    Expert confirmé
    Homme Profil pro
    Inscrit en
    septembre 2006
    Messages
    2 810
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations forums :
    Inscription : septembre 2006
    Messages : 2 810
    Points : 4 112
    Points
    4 112
    Par défaut
    Citation Envoyé par tatayo Voir le message
    Mais dans les deux cas je me demande bien comment on peut en arriver là.
    Il suffit d'un modèle implémentant une taxonomie avec une table par niveau hiérarchique et d'avoir plus de 100 "business objects/classes" héritant de la racine...
    Genre de modèle assez courant avec des outils comme Alfresco, Documentum, et d'autres... et dans ce genre d'utilisation, 100 classes c'est même assez moyen comme quantité.

  7. #7
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    10 005
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 005
    Points : 27 346
    Points
    27 346
    Par défaut
    Une centaine de clés qui pointent vers la même table.

    Et oui, on y arrive très vite.
    Si on considère, comme dans l'exemple que je donnais, une table Tiers, ou Annuaire, ou Personne, on l'appelle comme on veut, qui contient les informations de toutes les personnes physiques ou morales utilisées dans la base, on a donc toutes les personnes, parents, enfants, conjoints, notaires, fournisseurs, centre des impôts, magasins divers, etc, etc,
    C'est évidemment le cas le plus extrême, mais oui ça va très très vite.

    Et le ON DELETE CASCADE n'est pas la solution à tout. Et est même, dans beaucoup de cas, une solution très dangereuse.
    De toute façon, je n'en ai pas dans la base, donc ce problème-là est réglé
    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

Discussions similaires

  1. Ignorer les Erreurs émit par le système
    Par yann87 dans le forum Langage
    Réponses: 2
    Dernier message: 07/07/2009, 12h50
  2. ignorer les erreurs de certificas SSL pour DirectoryServices..
    Par olivier.schmitt2 dans le forum VB.NET
    Réponses: 1
    Dernier message: 06/02/2008, 14h08
  3. Filtre de texture qui ignore les "bords"
    Par valefor dans le forum OpenGL
    Réponses: 4
    Dernier message: 05/07/2007, 14h18
  4. Réponses: 3
    Dernier message: 21/06/2007, 12h53
  5. [pgAdminIII] Comment ignorer les erreurs de script
    Par Escandil dans le forum PostgreSQL
    Réponses: 6
    Dernier message: 22/07/2005, 12h03

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo