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 :

Bonnes pratiques Proc. stockées VS trigger via ADODB [2016]


Sujet :

Développement SQL Server

  1. #1
    Membre éclairé

    Profil pro
    Inscrit en
    janvier 2010
    Messages
    917
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2010
    Messages : 917
    Points : 841
    Points
    841
    Billets dans le blog
    25
    Par défaut Bonnes pratiques Proc. stockées VS trigger via ADODB
    Bonjour à tous

    SQL Server ne propose pas de trigger BEFORE UPDATE , INSERT DELETE mais à la place un triger UPDATE, INSERT DELETE INSTEAD OF

    Suite à un evement sur l'IHM qui appel via ADODB un ensemble de traitements sur les tables, quelle pratique faut-il appliquer?
    1. Déclarer une proc. Stock. dans laquelle il y a les traitements a faire
    2. Déclarer des triggers en INSTEAD OF.


    Je dois préciser qu'actuellement j'appelle des proc. Stock. via ADODB et que j'ai opté de ne pas gérer lles erreurs de violation de contraintes dans l'IHM en reimplementatnt les contraintes dans les proc. Stocks car
    1. Je ne connais pas toutes les codes d'erreur ADODB renvoyés en cas de violation de contrainte
    2. Je ne veux pas de message en cas de violation d'unicité


    Donc actuellement, j'appelle des proc. stock. sur l'événement CLICK d'objets type bouton depuis mon IHM et dans les proc. stock. je reimplemente les contraintes d'intégrité mais pas que. et vais prendre un cas concret pour illustration.

    Je récupère une base avec des tables dénormalisées qui au lieu d'avoir en ligne les tuiles (champ1, champ2), les ont colonne (implémentation de feuille EXCEL😠😡&#129324

    Donc les opérations d'INSERT UPDATE DELETE nécessitent du traitement préalable pour taper dans la bonne colonne.
    Donc
    1. Gestion des erreur dans le front ou implémentation des tests sur les contraintes ? J'avoue qu'après avoir posé la question, il me semble que la gestion dans le front est la meilleure solution car j'évite de reicrire du code pour rien. On faut espérer que les codes erreurs ADODB soient bien distincts entre par exemple une violation d'intégrité et un manque de paramètre
    2. proc. Stock ou trigger INSTEAD OF?


    Question subsidiaire, est-il possible d'ailleurs de traiter ce type de table dénormalisée via un trigger ?

    Merci par avance pour toute aide
    Mal nommer un objet, c'est ajouter au malheur de ce monde, car le mensonge est justement la grande misère humaine, c'est pourquoi la grande tâche humaine correspondante sera de ne pas servir le mensonge
    Poésie 44, n° 17 - Albert Camus

    Mes réponses vous ont aidés, un clic sur leur pouce vert
    Bonjour chez vous

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 890
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 20 890
    Points : 49 635
    Points
    49 635
    Billets dans le blog
    1
    Par défaut
    Il est extrêmement rare de devoir utiliser des déclencheurs BEFORE et encore plus dans MS SQL Server du fait de la présence d'auto incrément automatique (IDENTITY) et la possibilité de modifier en retour les données en cours de mise à jour (impossible sous Oracle notamment...). En effet, dans un déclencheur BEFORE les lignes n'étant pas encore insérées ou modifiées, on ne peut pas possible de s'en en jointure depuis la table cible... De ce fait leur seul intérêt serait de modifier la données avant la mise à jour, ce qui peut être fait même avec des déclencheurs AFTER...

    Je serais curieux de connaître le cas de figure qui nécessiterais un tel déclencheur...

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  3. #3
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 890
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 20 890
    Points : 49 635
    Points
    49 635
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par informer Voir le message
    ... j'ai opté de ne pas gérer lles erreurs de violation de contraintes dans l'IHM en reimplementatnt les contraintes dans les proc. Stocks car
    1. Je ne connais pas toutes les codes d'erreur ADODB renvoyés en cas de violation de contrainte
    2. Je ne veux pas de message en cas de violation d'unicité


    Donc actuellement, j'appelle des proc. stock. sur l'événement CLICK d'objets type bouton depuis mon IHM et dans les proc. stock. je reimplemente les contraintes d'intégrité...
    Vous ne pouvez pas implémenter de pseudo contrainte d'intégrité de type PRIMARY KEY, UNIQUE, FOREIGN KEY via un code itératif (déclencheur ou programme applicatif) et même des contraintes CHECK portant sur plus d'une colonne qui auront le même effet que des contraintes SQL du fait des aspect ensemblistes et concurrentiels inhérent aux SGBD Relationnels.

    De plus, toutes les contraintes, dans SQL Server, servent à augmenter les performances. L'optimiseur de SQL Server sait tirer partie des contraintes pour accélérer les accès aux données. S'en priver c'est rendre le système globalement lent, comme au temps des fichiers COBOL (pas la peine pour cela de prendre un SGBDR !).

    Si le fait qu'un message d'erreur apparait vous gène, il suffit de traiter l'erreur de manière interne à la procédure via un bloc de traitement d'exception TRY / CATCH.

    Enfin, si vous ne voulez par faire apparaître les messages standard, alors nommez vos contraintes à l'aide d'un code de référence, trappez-le et renvoyez une message plus approprié.
    Par exemple, pour mon client, actuel, (le clubmed) les noms des contraintes sont définis de la manière suivante :
    • PRIMARY KEY : __PK_???
    • FOREIGN KEY : __FK_???_!!!
    • UNIQUE : __UK_???_...
    • CHECK : __CK_???_...


    Ou :
    • ??? est le trigramme (unique) de la table visé
    • !!! le trigramme de la table cible
    • ... un complément d'information à la discrétion du concepteur du modèle


    Et une table de correspondance permet de retrouver la bon message à renvoyer :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    CREATE TABLE T_SQL_CONSTRAINT_ERROR_SCE
    (SCE_NAME      sysname PRIMARY KEY,
     SCE_MESSAGE   VARCHAR(1024));
    Une fois le message d'erreur récupéré dans le bloc CATCH via ERROR_MESSAGE()
    Il suffit de faire le filtre suivant pour trouver le bon message :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     SELECT SCE_MESSAGE
     FROM   T_SQL_CONSTRAINT_ERROR_SCE
     WHERE  ERROR_MESSAGE() LIKE '%' + REPLACE(SCE_NAME, '-', '?_') + '%' ESCAPE '?';

    Citation Envoyé par informer Voir le message
    mais pas que. et vais prendre un cas concret pour illustration.

    Je récupère une base avec des tables dénormalisées qui au lieu d'avoir en ligne les tuiles (champ1, champ2), les ont colonne (implémentation de feuille EXCEL😠😡&#129324

    Donc les opérations d'INSERT UPDATE DELETE nécessitent du traitement préalable pour taper dans la bonne colonne.
    Donc
    1. Gestion des erreur dans le front ou implémentation des tests sur les contraintes ? J'avoue qu'après avoir posé la question, il me semble que la gestion dans le front est la meilleure solution car j'évite de reicrire du code pour rien. On faut espérer que les codes erreurs ADODB soient bien distincts entre par exemple une violation d'intégrité et un manque de paramètre
    2. proc. Stock ou trigger INSTEAD OF?
    Encore une fois, pas la bonne conception...


    Citation Envoyé par informer Voir le message
    Question subsidiaire, est-il possible d'ailleurs de traiter ce type de table dénormalisée via un trigger ?

    Merci par avance pour toute aide
    Le mieux est d'utiliser des tables "tampons" qui servent d"intermédiaires avant d'insérer les données dans les tables cible (définitives) typées et contraintes. De telles tables tampons on des colonnes non typées (caractères) ce qui permet d'absorber même les erreurs de typages avant nettoyage.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  4. #4
    Membre éclairé

    Profil pro
    Inscrit en
    janvier 2010
    Messages
    917
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2010
    Messages : 917
    Points : 841
    Points
    841
    Billets dans le blog
    25
    Par défaut
    Merci SQLPro pour tes conseils

    Mal nommer un objet, c'est ajouter au malheur de ce monde, car le mensonge est justement la grande misère humaine, c'est pourquoi la grande tâche humaine correspondante sera de ne pas servir le mensonge
    Poésie 44, n° 17 - Albert Camus

    Mes réponses vous ont aidés, un clic sur leur pouce vert
    Bonjour chez vous

  5. #5
    Modérateur
    Avatar de Waldar
    Homme Profil pro
    Consultant Teradata
    Inscrit en
    septembre 2008
    Messages
    8 188
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Consultant Teradata
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2008
    Messages : 8 188
    Points : 17 070
    Points
    17 070
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Il est extrêmement rare de devoir utiliser des déclencheurs BEFORE...
    Je serais curieux de connaître le cas de figure qui nécessiterais un tel déclencheur...
    Ça m'arrivait d'en mettre (pas sur SQL-Server donc) pour éviter qu'un petit malin touche aux dates techniques (insertion, mise à jour, suppression) sur des tables de références importantes.
    Par exemple sur Oracle :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    create or replace trigger tgbu_matable
    before update of date_creation on matable
    for each row
    begin
        :new.date_creation := :old.date_creation;
    end;
    /
    Comme ça ma date de création n'est pas modifiable sans désactiver / supprimer le déclencheur, ce qui nécessite quelques privilèges élevés.
    C'est un vieil exemple bien entendu, aujourd'hui je ne ferai plus ça.

  6. #6
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 890
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 20 890
    Points : 49 635
    Points
    49 635
    Billets dans le blog
    1
    Par défaut
    Avec SQL Server on peut le faire avec un déclencheur AFTER....

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  7. #7
    Modérateur
    Avatar de Waldar
    Homme Profil pro
    Consultant Teradata
    Inscrit en
    septembre 2008
    Messages
    8 188
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Consultant Teradata
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2008
    Messages : 8 188
    Points : 17 070
    Points
    17 070
    Par défaut
    Oui et certainement dans d'autres SGBD aussi, après il faut voir si le déclencheur after ne fait pas deux fois la modifications (une fois avant et une autre fois après).

    De manière générale j'essaie d'utiliser le moins possible les déclencheurs, je les ai toujours considéré comme étant du code caché.
    Si on n'y pense pas on peut chercher des heures, voire plus, un comportement qui nous parait anormal.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Procédures stockées - bonnes pratiques
    Par patic dans le forum Décisions SGBD
    Réponses: 7
    Dernier message: 01/01/2017, 14h46
  2. Réponses: 2
    Dernier message: 06/08/2014, 10h17
  3. Bonne pratique InnoDb/trigger/MyIsam
    Par flagodzki dans le forum Administration
    Réponses: 9
    Dernier message: 24/01/2012, 11h18
  4. Trigger / appel procedure / sql dynamique / bonnes pratiques
    Par Samish dans le forum SQL Procédural
    Réponses: 9
    Dernier message: 25/03/2011, 21h56
  5. [Procédures stockées] Bonnes pratiques de gestion des erreurs
    Par jbrasselet dans le forum Développement
    Réponses: 4
    Dernier message: 04/02/2009, 00h14

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