Ah et je suis parfaitement d'accord, le point d'entrée devrait être la procédure. Mais le problème c'est qu'une procédure ne peut contenir plusieurs conflits, alors qu'un même conflit peut contenir plusieurs procédures...
Le 23 avril 2010 11:28, Marie-Pierre CORONEL <mariepierre....@gmail.com> a écrit : > En fait, ça m'évitait potentiellement d'ajouter un champ dans les > tables secondaires qui contienne civil ou pénal (un "connecteur" pour > savoir à quelle table on se branche) de manière à différencier la > médiation civile 0 de la médiation pénale 0. Mais évidemment, moi je > reste sur 2 procédures et toi tu défends la procédure unique :D > > De mon côté, j'ai interrogé le service informatique de la mairie, > parce que si j'utilisais MySQL, ce n'est pas sur mon PC qu'il devrait > être installé mais sur l'un de leurs serveurs... > > Le 23 avril 2010 10:37, Docgranville <docgranvi...@aol.com> a écrit : >> Le 23/04/2010 09:45, Marie-Pierre CORONEL a écrit : >>> >>> Salut, >>> >>> Il y a quelque chose qui pourrait me permettre de réduire le nombre de >>> tables, c'est de jouer sur les clés (concaténation par exemple de >>> civ+numéro de médiation, pen+numéro de médiation). J'ai vu qu'il y >>> avait des fils sur le sujet dans le forum, mais prise par l'urgence, >>> je n'ai pas planché le sujet. Je vais aller voir, si ça peut se faire >>> sans programmation, ça allègerait considérablement la base. >>> >> >> Bonjour Marie-Pierre, >> >> Je n'ai pas encore eu le temps de répondre utilement à ton message d'hier >> soir, j'essaierai de le faire ce week-end. >> >> En revanche, je ne vois pas bien par quel moyen la concaténation que tu >> évoques pourrait être de nature à réduire le nombre de tes tables. >> >> Pour moi, le point de départ de la réflexion, c'est que l'objectif de cette >> base étant de gérer des procédures, il est indispensable que celles-ci >> soient regroupées dans une seule et unique table ; je pense vraiment que, si >> la médiation elle-même s'adresse aux personnes, la base de son côté, >> constitue une aide à la gestion de la procédure et doit donc être centrée >> sur elle ; en conséquence, le numéro d'identification unique de la procédure >> (la clef primaire dans la table regroupant les procédures) servira ensuite >> dans les autres tables, à identifier les personnes concernées par cette >> procédure, les évènements affectant cette procédure, etc, etc... ; et je >> pense que ça facilitera grandement la sortie de statistiques (parce que >> elles, j'imagine bien qu'elles portent sur les procédures, pas sur les >> personnes). >> >> D'ailleurs, l'ambigüité que tu soulignais entre le nom et la fonction de ta >> table Demandeurs, vient (selon moi) du fait quelle a une double fonction : >> identifier les parties ET marquer la saisine du service ; même si elles sont >> intimement liées (s'il n'y a pas de personnes, il n'y a pas de conflit et >> donc pas de médiation) et qu'une distinction peut paraître artificielle, je >> crois préférable (pour la souplesse d'utilisation et de maintenance >> ultérieure de ta base, d'enregistrer dans des tables séparées les données >> relatives aux procédures d'une part et celles relatives aux personnes >> concernées d'autre part. >> >> Il me semble que c'est cette démarche là qui devrait te permettre de réduire >> un peu le nombre de tes tables. >> >> 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
