re :) bon alors, ma réponse risque d'être tout aussi longue :D je vais commencer par te présenter mon contexte, ça t'apportera déjà quelques réponses je pense.
- Ma structure : une petite structure qui n'a pas les moyens d'avoir un développeur, qui dépend de la mairie pour l'informatique, laquelle n'a qu'un développeur qui par ailleurs est le chef du service et donc n'a aucun temps à nous consacrer. Peu d'argent aussi, d'autant que travaillant dans le social, tout ce qu'on consacre à autre chose que du social nous fend le coeur. - Des services en difficulté, de plus en plus de stats demandées, de moins en moins de personnel, même si les dossiers ne sont pas très nombreux (pour la médiation c'est à peu près 200 par an) les collègues ont toujours plus de mal à les produire (pour le service de médiation, demandées début janvier on les aura enfin fin mars, après plusieurs aller-retour liés aux insuffisances de la production, des statistiques bâclées et non contrôlées où les incohérences sautent au visage, simplement parce que la collègue a le plus grand mal à les intégrer dans son plan de charge) - Moi ex-programmeur de gestion, qui n'a pas vu une ligne de programme depuis 15 ans, n'a pas entretenu la moindre connaissance sur le sujet, la page était tournée, responsable des finances, puis responsable du personnel maintenant chargée de mission auprès de la direction, théoriquement affectée à l'élaboration de projet, je me sentais tellement concernée par base que je ne me suis même pas inscrite à la formation de migration... Alors, tu me dis que je devrais travailler sur Mysql par l'intermédiaire d'OOo, tu as sûrement raison, le truc c'est que je ne sais même pas comment on fait... Aujourd'hui, je suis clairement non-programmeur, la base doit fonctionner sans recours aux macros et surtout, je n'ai pas vocation à l'entretenir, c'est pour ça que je disais avoir cherché à la faire la plus pérenne possible (notamment, j'ai préféré les tables "utilitaires" aux listes de valeur, même quand il n'y avait que 2 ou 3 valeurs, sauf pour monsieur et madame) J'ai lu en effet comme toi l'avertissement notamment de Sophie sur le fait que Base était orienté mono utilisateur et que Sun (à l'époque) ne s'engageait pas sur autre chose, qu'il était donc déconseillé de l'utiliser en production. Mais avons-nous vraiment le choix quand nous sommes une petite structure sans informaticien et relativement peu de moyens ? Au passage, la base que je monte ne sera rien d'autre que mono-utilisateur, nous n'avons qu'une médiatrice et à mi-temps seulement (sauf pendant la période où on la partagera pour les éventuelles modifications à réaliser si mes tests n'ont pas été suffisants et j'ai déjà prévu qu'on s'entendrait sur les jours de la semaine). - Les partenaires de la médiation : il fut un temps (heureux) où il n'y avait que la justice qui ne demandait pas grand chose et le CCAS qui en demandait nettement plus. Mais en 2009 arrivée de la CAF, qui tâtonne, veut des infos puisque maintenant pour la médiation civile c'est surtout elle qui paye, décide par exemple qu'il faut 3 natures juridiques pour les entretiens d'info et deux seulement pour les médiations (les deux dernières pour les infos étant regroupées dans la dernière pour les médiations), nous crée en mars 2010 des infos collectives dont il n'avait jamais été question jusque là, mais qu'on devra dénombrer pour l'activité 2010. Mais même la justice n'est pas totalement d'accord avec elle-même selon qu'on a à faire au Procureur (médiations pénales) ou au Greffe du TGI, on ne nous demande pas tout à fait les mêmes renseignements (même si tu as eu le sentiment du contraire, il y a une ou deux variantes qui m'ont en effet obligée à démultiplier le nombre de tables). Là-dessus tu ajoutes les demandes CCAS qui sont parfois sur les mêmes domaines mais classifient différemment, et la vision du médiateur de sa propre activité... et ça donne ce que j'ai monté (notamment sur les résultats, j'ai composé avec les demandes des uns et des autres) :D - Sur la base elle-même : * En fait la table demandeurs est mal nommée. Je m'en suis rendu compte un peu tard, j'ai hésité à la renommer, (mais j'aurais eu tellement à reprendre...), elle devrait s'appeler "conflit" ou "parties au conflit" (parce que médiation est déjà pris par une autre table). Il faut concevoir que notre médiatrice ne connaît les individus qu'à travers leur conflit. Ma collègue, si elle a besoin de trouver des renseignements sur quelqu'un actuellement va chercher dans la chemise de la médiation correspondante, elle n'a pas une fiche par personne. Les individus ne sont pas repérés, ce sont les médiations qui le sont. J'ai pensé à la table que tu proposes, c'est comme ça que cette table se retrouve mal nommée, mais ça n'est pas adéquat. Il lui faudrait attribuer un n° à un individu qui ne peut en tout état de cause pas être convoqué seul par exemple. Jamais elle n'appellera une fiche qui ne concerne que l'une des deux parties (enfin... sauf si elle a été défaillante la partie en question). Donc il m'a paru plus simple de faire la table telle qu'elle existe actuellement plutôt que de créer différemment et de générer ensuite des vues. J'ai aussi demandé confirmation à ma collègue que les médiations n'étaient toujours qu'entre deux parties. Elle m'a affirmé qu'il pouvait y avoir plusieurs personnes participantes, mais que toujours ce plus ou moins grand nombre de personnes se répartissaient en 2 parties à l'origine du conflit (l'équivalent de "consorts" utilisé par la justice). De fait, une médiation qui comporterait 3 parties ne rentrerait pas non plus dans les cases de la justice et de la CAF... Ma collègue souhaite un accès à l'intégralité des données 'immédiates" concernant les médiations (les éléments sur les deux parties et la médiation) d'où le formulaire très complet de saisie des demandeurs et des médiations. Tiens d'ailleurs, comment base traiterait le fait de rentrer les deux parties dans une même table à partir du même formulaire ? Lequel serait le premier enregistrement et lequel le suivant ? J'ai aussi séparé les procédures (médiations civiles et médiations pénales) et les personnes concernées (demandeurs) ^^ Sur le fond, les deux mêmes parties peuvent être arrivées par la justice, la médiation conclue, et demander à revenir en complément, on est obligés de la rentrer comme une nouvelle médiation, parce que la justice par exemple n'y participera pas, spontanée cette fois, elles n'en demeurent pas moins la suite du règlement du conflit, ma collègue les a appelées ses médiations "service après-vente", d'où le choix de présentation d'une liste de médiations sous un même numéro de conflit, et elles peuvent être à l'origine pénales... Ce qui m'a aussi rendu les choses un peu compliqué ce sont les informations préalables (en dehors de ce dont j'ai déjà parlé sur les natures juridiques). Ces informations peuvent ne pas être suivies par une médiation. Et une médiation peut ne pas avoir été précédée d'une information préalable. La CAF a cependant conçu un document unique où l'on doit donner les mêmes informations sur le mode de connaissance, l'origine judiciaire,... qu'il s'agisse d'une simple information préalable, d'une information préalable suivie d'une médiation ou d'une médiation sans information préalable... Comme tu le disais j'ai déjà beaucoup travaillé sur cette base, et ma collègue l'attend avec impatience car elle a déjà près de 4 mois de médiations à rentrer. Dommage que je n'ai pas commencé par les requêtes (je sais, c'est un non-sens :D) je te l'aurais soumise beaucoup plus tôt :D. Maintenant que tu sais presque tout, que me proposes-tu de faisable ? :D Le 22 avril 2010 17:18, Docgranville <docgranvi...@aol.com> a écrit : > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@fr.openoffice.org For additional commands, e-mail: users-h...@fr.openoffice.org
