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😠😡🤬)

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

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 +

Citation:

---

Envoyé par informer

... 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:

---

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:

---

1 2 3

SELECT SCE_MESSAGE FROM T_SQL_CONSTRAINT_ERROR_SCE WHERE ERROR_MESSAGE() LIKE '%' + REPLACE(SCE_NAME, '-', '?_') + '%' ESCAPE '?';

---

Citation:

---

Envoyé par informer

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😠😡🤬)

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

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 +

Merci SQLPro pour tes conseils

:ccool:

Citation:

---

Envoyé par SQLpro

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:

---

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.

Avec SQL Server on peut le faire avec un déclencheur AFTER....

A +

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.