Discussion :

[sdinot]

Bonjour,

En premier lieu, j'annonce tout de suite que j'ai peu d'expérience en SGBD et en SQL. Ne soyez donc pas étonnés s'il vous semble que je prends le problème à l'envers. Dans ce dernier cas, je vous serais reconnaissant de m'indiquer « LA » bonne manière de traiter la chose.

Environnement : PostgreSQL 7.4.2 sous GNU/Linux

Mon souci est le suivant. J'ai 3 tables :

• - personne (liste des personnes ayant un jour adhéré à l'association) ;

• - adhesion (une personne pouvant quitter l'association puis y réadhérer, on peut avoir plusieurs fiches « adhesion » pour une seule personne) ;

• - cotisation (liée à une adhésion et à une personne).

Une requête SQL peut m'indiquer :

• - si une personne est adhérente à l'heure actuelle ;

• - si un adhérent est à jour de sa cotisation ;

• - l'ancienneté d'un adhérent.

Cependant, calculer ces informations à chaque fois est pénible et alourdit considérablement les requêtes. J'aimerais donc ajouter à la table « personne » des champs qui me fourniraient directement ces informations :

• - actif (la personne est-elle adhérente à l'heure actuelle ?) ;

• - ajour (l'adhérent est-elle à jour de cotisation ?) ;

• - anciennete (nombre de jours écoulés depuis l'adhésion).

Pour le premier champ (actif), ce n'est pas un problème. Des triggers sur INSERT et UPDATE dans la table adhesion me permettent de le mettre à jour à bon escient.

Pour le second (ajour), je peux bien créer un trigger pour basculer ce booléen à TRUE lorsque j'ajoute une cotisation. Par contre, lorsque l'échéance est dépassée, ce champ doit basculer à FALSE. Or, aucun événement interne ne me permet de déclencher une procédure de mise à jour.

Pour le troisième, le problème est du même ordre. Chaque jour, ce champ doit être incrémenté mais aucun événement interne ne me donne l'occasion de le faire.

Après réflexion, je me fiche bien que ces informations soient à jour à chaque instant. Ce qui m'importe, c'est qu'elles le soient lorsque j'adresse une requête à la base.

Or, s'il est possible d'associer un trigger à un INSERT, UPDATE ou DELETE, je n'ai rien trouvé de tel pour un SELECT.

Avez-vous une idée ?

Sébastien

PS : J'ai conscience qu'un trigger sur SELECT peut considérablement ralentir une base mais l'on peut très bien ajouter une table de gestion pour enregistrer la date de dernière mise à jour des champs « actif », « ajour » et « anciennete » et n'effectuer cette mise à jour qu'une fois par jour.

[Krapulax]

Salut,

J'ai quelques questions pour toi pour bien cerner le problème :
- as-tu mis des index sur tes tables ?
- pourquoi ne pas créer simplement des vues ?
- à combien estimes-tu le nombre d'enregistements dans tes tables (surtout celle des personnes) ?

@+

[Bouboubou]

Cependant, calculer ces informations à chaque fois est pénible et alourdit considérablement les requêtes. J'aimerais donc ajouter à la table « personne » des champs qui me fourniraient directement ces informations :


- actif (la personne est-elle adhérente à l'heure actuelle ?) ;


- ajour (l'adhérent est-elle à jour de cotisation ?) ;


- anciennete (nombre de jours écoulés depuis l'adhésion).

non,non,... c'est de la redondance d'information. Je crois que ton problème vient de ton modèle EA. Si tu mets des attributs, tu vas gagner en temps de réponse pour tes requêtes, mais tu es sur que dans quelques temps(sûrement très rapidement) ta bd va se trouver dans un état incohérent. Je prends les paris! Et là, bonjour les problèmes!

Repense à ton MCD (modèle conceptuel de données)! Les réponses aux questions de Krapulax m'intéresse. Si malgré une bonne gestion de tes index et si vraiment tes tables contiennent un grand nombre de données: alors il faut travailler l'optimisation de tes requêtes(fait des plan d'exécution) et peut-être rajouter des index.

Donne nous ton MCD (le mieux serait de poser la question dans le forum modélisation; Certaines personnes sont très compétentes!).

Je veux volontier t'aider pour l'optimisation des requêtes, mais avant cela il faut un MCD qui tienne la route, sinon tu vas faire que du bricolage. Je veux bien t'aider également pour ton modèle!

A+

[sdinot]

- as-tu mis des index sur tes tables ?

Oui

- pourquoi ne pas créer simplement des vues ?

Les vues sont effectivement pratiques mais, si j'ai bien compris, il s'agit en fait de requêtes effectuées à chaque fois qu'une autre requête y fait référence.

Le problème que je soulève ici se pose dans un contexte associatif et avec une base de taille très réduite, ces requêtes systématiques ne sont donc pas très pénalisantes et l'impact est modéré.

Par contre, d'ici quelques temps, dans le cadre professionnel, je serai confronté à la même problématique avec une base beaucoup plus lourde (4 Go de données, plusieurs millions d'enregistrements). Dans ce contexte, je préfère éviter les vues et les requêtes redondantes.

- à combien estimes-tu le nombre d'enregistements dans tes tables (surtout celle des personnes) ?

Taille ridicule. A l'heure actuelle environ 300 personnes (+50 personnes/an), autant d'adhésions (+50 adhésions/an) et 400 cotisations (+300 cotisations/an).

Sébastien

[Bouboubou]

Taille ridicule. A l'heure actuelle environ 300 personnes (+50 personnes/an), autant d'adhésions (+50 adhésions/an) et 400 cotisations (+300 cotisations/an).

Alors tu ne devrais pas avoir de problème de performance. Refléchi de nouveau à ton MCD!

[Krapulax]

A mon avis, il n'a pas de problème de performance actuellement mais il essayait d'extrapoler les perfs sur une base de 4Go.

Bouboubou a raison, le premier moyen de gagné en perf, c'est d'avoir un bon modèle MCD, et de respecter quelques régles que tu pourras trouver ici : http://sqlpro.developpez.com/OptimSQL/SQL_optim.html

Quand tu t'attaqueras à ta base de 4Go, l'autre piste sera peut-être un tuning plus fin de Postgresql et de ton hardware : Cf http://techdocs.postgresql.org/#techguides - Section Optimizing.

[sdinot]

non,non,... c'est de la redondance d'information. Je crois que ton problème vient de ton modèle EA.

N'étant pas un pro du domaine (le mien est plutôt le développement C/C++) et ayant appris sur le tas, je n'ai pas de doute sur le fait que mon modèle soit « perfectible » !

Si tu mets des attributs, tu vas gagner en temps de réponse pour tes requêtes, mais tu es sur que dans quelques temps(sûrement très rapidement) ta bd va se trouver dans un état incohérent. Je prends les paris! Et là, bonjour les problèmes!

La cohérence des données est justement mon souci principal. J'ai donc fixé un certain nombre de contraintes d'intégrité. Récemment, j'ai découvert les triggers et j'ai trouvé le principe génial ! Pendant un temps, j'ai même cru qu'ils allaient résoudre tous mes problèmes. Puis j'ai réalisé que certaines informations se périmaient sans que le moindre « événement » intrinsèque à la base ne permette d'y remédier...

Repense à ton MCD (modèle conceptuel de données)! Les réponses aux questions de Krapulax m'intéresse. Si malgré une bonne gestion de tes index et si vraiment tes tables contiennent un grand nombre de données: alors il faut travailler l'optimisation de tes requêtes(fait des plan d'exécution) et peut-être rajouter des index.

Dans le cas présent, l'optimisation des requêtes n'est pas vraiment utile (par contre, je vais devoir y faire sérieusement attention dans le cadre du projet professionnel que j'évoquais dans une réponse précédente).

Donne nous ton MCD (le mieux serait de poser la question dans le forum modélisation; Certaines personnes sont très compétentes!).

Je me suis justement posé la question du forum et je me suis finalement dit que la réponse dépendait du SGBD.

Je veux volontier t'aider pour l'optimisation des requêtes, mais avant cela il faut un MCD qui tienne la route, sinon tu vas faire que du bricolage. Je veux bien t'aider également pour ton modèle!

Je ne l'ai pas sous la main sur l'instant mais je le posterai ce week-end.

Sébastien