Procédures et organisation de tests

Bonjour,
Actuellement, je suis en train de réaliser plusieurs procédures effectuant des mises à jour de ma base.
Mon souci est que dans chacune de procédures j'ai toute une liste de tests à effectuer sur les valeurs :
- cohérence de la donnée (existante dans la table de référence)
- date comprise entre telle date et telle date
- certains valeurs ne doivent pas être nulles

Actuellement, j'effectue ces tests dans chacunes de mes procédures mais lors d'une modif, je dois aller vérifier dans plusieurs procédures et effectuer la mise à jour.

J'aurai souhaité centraliser ces tests mais je ne vois pas comment m'organiser.
Auriez-vous une piste, s'il vous plait?
Cordialement
Pinocchio

Citation:

---

Envoyé par pinocchio

Bonjour,
- cohérence de la donnée (existante dans la table de référence)
- date comprise entre telle date et telle date
- certains valeurs ne doivent pas être nulles
Cordialement
Pinocchio

---

En somme, vous voulez réinventer respectivement

- les contraintes d'intégrité (FK)
- les contraintes de vérifications (check constraint)
- les contraintes de vérifications (NOT NULL constraint)

En ne tenant pas compte de l'aspect mutli-utilisateurs et de l'utilité que les contraintes citées plus haut peuvent avoir dans l'aide à la décision que doit prendre l'optimisateur d'Oracle lorsqu'il sera en train d'affecter un plan d'exécution aux selects invoquant des tables contenants ces colonnes et ces contraintes.

Bref, merci de bien vouloir privilégier les contraintes à vos propres vérifications faites plus haut (dans les procédures)

Bonjour et merci pour votre réponse.
Je suis entièrement d'accord et je me bats pour mettre en place un peu plus de contraintes et de cohérence.
Mon souci est que je suis face à une porte close sur toute amélioration de bdd.
Je recherche donc des paliatifs qui sont bien entendu pas des solutions à mettre en place en temps normal.
La base date d'il y a plus de 10 ans et dans les hautes sphères, on a peur du changement.

Tu peux centraliser ces tests dans des fonctions par contre niveau optimisation... pas glop !

Merci
Quand tu dis "pas glop", c'est au niveau performance ou au niveau temps de réalisation de ta procédure d'origine?
L'appel à une fonction plus le test est-il beaucoup plus long en exécution que le test lui-même?

Les tests sont assez simples avec des comparaisons de date sur une période flottante par exemple, des valeurs obligatoires, ...

En terme de performances je veux dire, si tu fais un INSERT d'1 million de lignes, tu appelleras 1 millions de fois la fonction. Dans ce cas il est préférable d'implémenter tes règles de contrôles directement dans la requête.

Après ça dépend aussi de la complexité de la fonction, on peut imaginer quelque chose dans le genre par exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

CREATE OR REPLACE FUNCTION CHECK_TABLE (pe_table IN user_tables.table_name%TYPE, pe_query IN VARCHAR2) RETURN NUMBER IS NbRows NUMBER; BEGIN EXECUTE IMMEDIATE 'SELECT count(*) FROM '||pe_table||' '||pe_query INTO NbRows; RETURN NbRows; END; /   CREATE OR REPLACE FUNCTION CHECK_DATES (pe_date IN DATE, pe_date_min IN DATE, pe_date_max IN DATE) RETURN NUMBER IS BEGIN IF pe_date BETWEEN pe_date_min AND pe_date_max THEN RETURN 1; ELSE RETURN 0; END IF; END; /   CREATE OR REPLACE FUNCTION CHECK_NULL (pe_data IN VARCHAR2) RETURN NUMBER IS BEGIN IF pe_data IS NULL THEN RETURN 1; ELSE RETURN 0; END IF; END; /

---

Par contre tout dépend de l'utilisation que tu veux en faire.
Les fonctions ci-dessus te ramènent 0 ou 1 (voir n pour la CHECK_TABLE), mais tu peux tout aussi faire un RAISE si le retour est 0 afin de provoquer une erreur

Merci pour les précisions.
En fait ce ne sera que pour des inserts/update de peu d'enregistrements.

Et pour les fonctions, elles seront vraiment proche de ce que tu as fais, elles sont plutôt courtes et rapide.
Merci beaucoup