Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
j'ai créé 3 tables pour "historiser" les adresses de facturation:
t_address t_invoice_address t_invoice_address_history
adr_id PK cli_id PK iah__id PK
cli_id adr_id adr_id
.... iva_date_begin iah_date_begin
adr_date_create iah_date_end
Pour info, t_invoice_address référence l'adresse de facturation courante et t_invoice_address_history les adresses de facturation pour l'édition de factures avec d'anciennes adresses.
Je suis en train de créer des jeux de test et je pensais renforcer la cohérence du modèle de données.
Par ex, lors de l'INSERT/UPDATE d'un record dans t_invoice_address la valeur de iva_date_begin ne devra pas être antérieure à t_address.adr_date_create
J'ai quelques questions concernant la mise en place de ces vérifications:
1. Je pense utiliser un trigger pour les réaliser. Existe-t-il une alternative?
2. Si j'utilise un trigger, je ne peut pas y effectuer la comparaison. Je dois utiliser une procédure pour le faire?
2. J'aurai besoin de la valeur de t_invoice_address.iva_date_begin dans la procédure. Je peux:
- la passer en paramètre depuis le trigger;
- utiliser une "procédure trigger" afin de disposer de la variable NEW directement.
2.1. La seconde solution semble la plus simple mais y a-t-il des inconvénients à utiliser une "procédure trigger" plutôt qu'une "procédure"?
2.2. Si j'utilise la seconde, suis-je certain que la valeur de NEW sera celle du trigger qui a appelé la procédure et pas d'un autre (appelé entre temps) ou faudra-t-il
vérifier le nom du trigger appelant?
3. Si la comparaison échoue (date non conforme), la procédure génère une erreur. Dois-je me soucier de la valeur de retour de la procédure? L'erreur arrête-t-elle son exécution comme dans d'autres langages?
4. S'il n'y a pas d'erreur est-ce que la procédure doit retourner NULL ou les données à insérer/modifier - dans le cas d'une "procédure trigger"?
Bon je m'arrête là - pour l'instant. Merci d'avance pour votre aide.
Hors ligne
1: Pas vraiment. On peut utiliser une contrainte check appelant une fonction, mais ça n'est pas officiellement supporté dans PostgreSQL si je me souviens bien
2: On doit de toutes façons utiliser une fonction, qui sera appelée par le trigger (le create trigger référence une fonction de type de retour trigger)
2.1: Non, on ne peut pas la passer en paramètre au trigger (on n'a pas l'info). Dans la fonction trigger appelée par le trigger, on aura accès à l'enregistrement (s'il s'agit bien d'un trigger sur enregistrement). De là, rien n'interdit dans la fonction de faire une requête sur t_invoice_address. On ne peut pas utiliser une «procedure» pour un trigger, on doit utiliser une procedure trigger. Dont la seule différence est qu'elle est de type de retour trigger, et qu'elle dispose de quelques variables déclarées implicitement (les TG_, NEW, OLD…). À part ça c'est une fonction comme une autre.
2.2: new n'est pas une valeur de trigger, mais une valeur d'enregistrement: l'enregistrement modifié.
3: Dans la fonction trigger, vous devez avoir deux chemins: un qui se termine avec RETURN NEW, pour dire que tout s'est bien passé, et un autre qui génère une exception (un RAISE), qui va retourner un message d'erreur à l'utilisateur (le plus explicite possible).
4: S'il n'y a pas d'erreur, la fonction doit retourner NEW. Retourner NULL fait que le trigger annule l'opération de modification en cours (sans erreur, elle ne fait simplement rien)
Marc.
Hors ligne
Merci pour toutes ces précisions.
Dernière modification par pyd001 (13/12/2011 21:59:34)
Hors ligne
1: Pas vraiment. On peut utiliser une contrainte check appelant une fonction, mais ça n'est pas officiellement supporté dans PostgreSQL si je me souviens bien
Ou avez vous vu cela ?
Pour ma part cela est supporté depuis longtemps et fait plutôt partie des bonnes pratiques, car c'est bien plus perormant qu'un trigger.
Pour information l'article ou j'ai démontré cela : Contraintes CHECK sur tables externe avec PostGreSQL
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Marc.
Hors ligne
Ah oui, c'est aussi écrit en toutes lettres dans la doc, évidemment.
Marc.
Hors ligne
Pages : 1
