[sf 1.4.x] relation n:n ou 3 tables avec relations 0:n ? [Résolu]

[erdesc]

Bonjour,

Tout d'abord, j'espère que je poste au bon endroit, puisque ma question touche beaucoup à Doctrine, mais pas uniquement.

Je travaille sur une application qui permet de gérer
- des clubs de sport,
- des catégories d'équipes (D1, D2, etc.)
- et une relation n:n entre les clubs et les catégories d'équipes, correspondant à peu près à des équipes, sachant qu'il peut y avoir plusieurs équipes par catégorie et pour un club.

Pour l'exemple, les tables club et equipe sont composées de 2 champs id et name chacune, et la table equipe contient les champs club_id (clé primaire), categorie_id (clé primaire) et nombre (voir le modèle de données en pièce jointe).

Voici le schema.yml correspondant :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Club:
  columns:
    id:             { type: integer(4), unsigned: true, primary: true, autoincrement: true }
    name:           { type: string(100), notnull: true, unique: true }
 
Categorie:
  columns:
    id:             { type: integer(4), unsigned: true, primary: true, autoincrement: true }
    name:           { type: string(100), notnull: true, unique: true }
  relations:
    Club:
      foreignAlias: Categories
      class: Club
      refClass: Equipe
 
Equipe:
  actAs:
    Sluggable:
      fields:       [ club_id, categorie_id ]
  columns:
    club_id:        { type: integer(4), unsigned: true, primary: true }
    categorie_id:   { type: integer(4), unsigned: true, primary: true }
    nombre:         { type: integer(2), unsigned: true, default: 1 }
  relations:
    Club:
      foreignAlias: Equipes
    Categorie:
      foreignAlias: Equipes

Ça fait quelques jours que je parcours les forums et la documentation de symfony pour comprendre comment valider le formulaire d'ajout d'équipes, et je suis tombé sur cette remarque de Michel Rotta sur les relations n:n avec doctrine :

La table de jointure ne peut comporter que deux champs, le champs : idLiensnomenclature est en trop. La clefs unique doit être constituée par les deux champs de liaison (on ne peut avoir deux liaisons A1 vers B1... cette liaison doit être unique, d'où la clef).

Donc dans mon cas, faut-il que je créée une table equipe avec son propre id et deux relations 0,n vers les tables club et categorie ?

Un avis, un lien qui m'aurait échappé ?

Merci !

Eric

[Herode]

Faire des relations avec Doctrine n-n entre des tables ayant des clés multiples est effectivement impossible.

En outre, ton modèle me semble curieux. Peut-être des détails fonctionnels m'échappent-ils mais définir une équipe avec comme clé : club_id / categorie_id me laisse perplexe. Cela signifie que dès qu'une équipe change de catégorie, elle change d'identifiant (sa clé primaire change) donc tous les liens pointant vers elle cessent d'être valides. La maintenance et le codage vont être acrobatiques...

A moins d'avoir une forte raison fonctionnelle pour construire ton modèle ainsi, je mettrais un id classique à la table équipe et deux clés étrangères club_id + categorie_id pointant vers le club de rattachement de l'équipe et la catégorie à laquelle appartient l'équipe. Et le n-n club-catégorie apparait naturellement avec la médiation de la table Equipe.

Non ?

[erdesc]

Bonjour Herode,

Merci de ta réponse.

La table Equipe est en fait la table de relation entre les clubs et les catégories, à ceci près qu'il y a le champ nombre en plus. Il ne s'agit donc pas d'objets Equipe, les équipes ne sont pas nominatives, il s'agit juste connaître leur présence et de les compter, ce qui fait que si une équipe change de catégorie, le nombre est incrémenté dans sa nouvelle catégorie et décrémenté dans l'ancienne.

Je crois que je vais devoir suivre ta recommandation, parce que ma solution m'oblige à des contorsions que je ne maîtrise pas.

J'essaie et si ça fonctionne, je repasserai pour passer le message en [Résolu].

Éric

[erdesc]

Bonjour,

En effet, en passant les categorie_id et club_id en clés étrangères et en remettant une clé primaire sur la table équipe, ça évite pas mal de soucis.

Ceci-dit, je ne comprends pas bien cette limite.

Bonne journée à tous et encore merci Hérode !

Éric

[Michel Rotta]

Ce n'est pas un problème doctrine 1 mais un problème d'analyse.

La table équipe n'est pas une table de jointure mais une entité à part entière, la table catégories est un argument de la table équipe.

Tu as une liaison n-1 entre club et équipe (un club peut avoir plusieurs équipe, une équipe appartiens toujours à un club) et un argument en liaison 1-n entre équipe et catégorie (une équipe à une catégorie et une catégorie peut être affectée à plusieurs équipes).

Sur le plan purement relationnel on pourrait voir une liaison entre club et catégorie, mais les entités sont club et équipe, catégorie n'est qu'un qualifiant de l'équipe.

CQFD

[erdesc]

Bonjour Michel,

Merci pour ta réponse.

Tu as une liaison n-1 entre club et équipe (un club peut avoir plusieurs équipe, une équipe appartiens toujours à un club) et un argument en liaison 1-n entre équipe et catégorie (une équipe à une catégorie et une catégorie peut être affectée à plusieurs équipes).

Je crois que c'est un peu différent dans mon cas, puisque la table des équipes représente un nombre d'équipes par catégorie et par club. Il ne peut y avoir qu'une occurrence d'équipe par club et par catégorie. Une catégorie ne peut être affectée qu'à une occurrence d'équipe par club.

J'ai fait ce schéma parce que mon client ne souhaite pas enregistrer chaque équipe de chaque club, mais seulement les compter.

Merci et bonne journée !

Éric

[Michel Rotta]

Avec ces informations supplémentaire, c'est, en effet, un peu différent.

Tu as donc club et catégories comme entité et le nombre d'équipe en argument de la liaison n-n.

Ton seul problème est que doctrine ne sait pas gérer les relations n-n avec un argument.

Il faut donc les considérer comme deux relations 1-n.

[erdesc]

Bonjour Michel,

C'est ce que j'ai fini par faire. J'y ai juste perdu pas mal de temps, mais c'est la règle de l'apprentissage.

Bonne journée et encore merci !

Éric