Le 21/04/2010 19:11, Marie-Pierre CORONEL a écrit :
re bonjour,
non non, je ne tiens pas à traiter les 3 régimes différemment, j'avais
essayé d'obtenir les calculs sur les 3 d'un coup mais je n'obtenais
jamais un chiffre juste -_- La seule fois où j'ai enfin obtenu un
chiffre juste c'est avec le système des 3 requêtes sauf quand j'ai
testé avec 0 occurence. Là je suis rentrée chez moi, mais je
regarderai tes requêtes demain.
Je veux bien qu'on discute de la rigidité de ma base, parce que j'ai
essayé de faire le plus pérenne possible et donc le contraire :'( mais
bon...
a+
Re-Bonjour Marie-Pierre,
Bon, vu que tu as l'air d'avoir beaucoup bossé sur ce truc et que la
pérennité de la base (ainsi que sa fonctionnalité) est une composante
essentielle, je crois utile, avant que tu ne continues à travailler sur
tes requêtes de te proposer une petite pause réflexion sur la structure
de ta base elle-même.
Tout d'abord sur un plan général, je ne sais pas s'il est véritablement
conseillé d'utiliser Base en production ; c'est un module de OOo qui
comporte encore beaucoup d'imperfections et il me semble avoir lu en
plusieurs endroits (y compris sur ces liste, y compris par des membres
du projet) qu'il n'était pas trop conseillé d'utiliser ce module dans un
cadre professionnel ; je ne sais pas si une telle solution éliminerait
tout ou partie des "risques" (en vertu desquels la prudence est souvent
recommandée à l'égard de Base) mais, pour rester dans le libre,
peut-être pourrais-tu créer cette base avec Mysql et t'y connecter avec
Base (tes formulaires fonctionneront et tu pourras créer des requêtes
sans aucune difficulté, mais en revanche, je pense que tu ne pourras pas
apporter de modifications à la structure de tes tables avec Base, et à
chaque fois que tu voudras le faire, il te faudra passer par Mysql) ;
qui plus est, Hsqldb ne gère pas les bases multi-utilisateurs et ça peut
avoir une influence sur l'utilisation de ta base de données.
En ce qui concerne ta base elle-même, j'ai compris qu'elle allait servir
à gérer le suivi d'un service de médiation, certaines étant civiles,
d'autres étant pénales.
La première question que je me pose, c'est pourquoi enregistrer dans
deux tables différentes, les médiations civiles et les médiations
pénales ? Ça t'oblige ensuite à dupliquer plein de tables comme, par
exemple, les tables "Aide mémoire" alors qu'elles ont la même structure
; mieux encore, les tables relatives aux liens entre les parties, qui
regroupent le même type d'informations (même si je suis conscient que
certains types de liens ne seront utiles -ou ne devront être
utilisables- que dans tel type de médiation et pas dans l'autre).
C'est en cela que je pense que ta base est un peu trop rigide.
En y réfléchissant comme ça, au débotté, je me dis que les
caractéristiques sont les suivantes : le service concerné est saisi
d'une médiation ; il s'agit d'une "procédure" qui peut disposer de deux
natures différentes, provenir de plusieurs sources et devra faire
l'objet d'un suivi ; elle concerne, généralement deux ou plusieurs
personnes.
Du coup, je serais tenté de me dire que j'ai besoin de trois tables
initiales :
- une table regroupant toutes les médiations dont le service a été saisi
et contenant leurs caractéristiques (origine, nature,...)
- une table regroupant les personnes concernées avec tous les
renseignements les concernant ;
- une table regroupant les informations relatives au suivi (les
évènements se déroulant dans le cadre de la médiation).
Ces trois tables là vont être les tables principales de ma base puisque
ce sont elles qui vont évoluer tous les jours.
Viennent ensuite les tables que je qualifierais de "secondaires" ou de
"utilitaires" ; en fait, ce sont les tables dans lesquelles seront
stockées des données récurrentes (les liens entre les parties par
exemple, le mode de connaissance, les modalités de saisine du service,
les suites réservées,...).
Ensuite, tu peux faire des requêtes (avec leurs vues et leurs
formulaires associés) pour obtenir un regard limité à telle ou telle
portion de ta base (un formulaire uniquement dédié à la consultation et
ne regroupant que les médiations civiles et un autre pour les pénales).
L'une des choses qui me "gênent" un peu dans ta base, telle qu'elle est
actuellement conçue, c'est que, par exemple, pour les demandeurs, la
partie 1 et la partie 2 figurent dans le même enregistrement mais que
l'on renseigne exactement les mêmes informations pour chacune des
parties ; pour ma part, j'aurais tendance à faire figurer dans cette
table qu'un seul champ nom, un seul champ prénom, etc... ; la clef
primaire servirait alors, dans la table relatives aux médiations de clef
externe, permettant d'identifier le statut de partie 1 ou de partie 2 de
chaque personne ; et que fais-tu si un jour tu as une médiation avec 3
parties ?
Pour résumer je séparerais d'un côté les procédures (et leurs
caractéristiques) et de l'autre les personnes concernées ; dans ta table
demandeur, dans la mesure où tu fais figurer le nom, soit dans la
colonne partie 1, soit dans la colonne partie 2, tu donnes déjà des
éléments sur la médiation elle-même (alors que dans ma vision, cette
info là ne figure que dans la table regroupant les procédures).
Bon, comme mon post commence à être un peu long, je m'arrête là mais me
tiens à ta disposition pour en discuter un peu plus si tu veux.
A+
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@fr.openoffice.org
For additional commands, e-mail: users-h...@fr.openoffice.org
