Désolé de ne pas avoir répondu plutôt, mais je suis un peu fatigué et débordé.
Pour ma part j'ai effectivement travaillé un peu sur le sujet à partir de la modélisation jointe (réalisée avec MysqlWorkBench 5.2. Je considère que chaque club est totalement indépendant avec son propre serveur, et que la fédération est logé à la même enseigne. D'où les divers champs de la table club qui contient le compte utilise lors de la connexion aux clubs dont in veut récupérer les informations.
L'idée est :
je me connecte sur la base du club visé et le lance le script qui renvoie le rapporta attendu sous la forme d'un fichier à finaliser la seule imposition est que les clubs aient déclarées aux aussi l'utilisateur dans la tables des logins.
Je suis partir de la branche "Fédération" pour le chargement dans mon environnement de développement qui est sous NetBeans 6.9
Le 14/02/2011 20:30, Antoine Viel a écrit :
On Mon, 14 Feb 2011 15:23:28 +0100 Jean Saquet <Jean.Saquet@xxxxxxxxxxxxxxx> wrote:Il faut que je réfléchisse un peu. Juste une remarque : la table asso doit faire référence à une clé d'accès sur le même serveur ou sur un autre. Il y a donc une relation "structure - sous-structure" qu'il faut modéliser quelque part. (la table asso de Caen par exemple doit indiquer qu'elle adhère à la Fenoram, et celle de la Fenoram qu'elle a Caen comme adhérentoui, sur le diagramme, j'ai dessiné une boucle depuis l'entité "assos" sur elle-même. Implicitement j'ai fait l'hypothèse qu'une asso n'adhère qu'à une autre asso, d'où les cardinalités 1:N. Du coup, une occurence d'"assos" n'a besoin que de 2 clés : - sa clé primaire nommée "cleasso" (notée PK), que je comptais unifier avec la clé correspondante de la base des clubs (VERNON.MTL, CAEN.MTL, FENORAM.FDR, ...) - une clé étrangère "clefede" (notée FK, éventuellement vide) indiquant à quelle autre asso (ici au sens de fédération) elle adhère C'est pourquoi, sur ce cas restreint d'une relation 1:N, il n'est pas nécessaire de matérialiser la relation inverse fédération->club, une jointure SQL étant suffisante pour représenter la relation directe "...adhère à...". Une hiérarchie de fédérations régionales / nationales est d'ailleurs représentable. Toutefois, je n'ai pour l'instant pas pris en compte les cas (possibles ou souhaitables ?) d'adhésion multiple, et encore moins le cas de fédérations gérées sur un autre serveur.Par ailleurs, les logins des personnes qui administrent plusieurs bases pour des structures différentes me semblent difficile à mettre en place : il faut à mon avis une entrée dans chaque base, pour chaque structure administrée.effectivemment, ma proposition n'est pas très satisfaisante sur ce point, les attributions de responsabilité personne/assos seraient assez compliquées à gérer. Je vais y réfléchir. Antoine