Discussion :

[pinocchio]

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

[Mohamed.Houri]

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)

[pinocchio]

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.

[Scriuiw]

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

[pinocchio]

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

[Scriuiw]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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