Discussion :

[d10g3n]

(re)Bonjour,

Une question de philo plus qu'une question technique

je suis en train d'essayer de comprendre au mieux comment bien utiliser symfony et doctrine. En sachant que j'ai l'habitude de commencer un projet en utilisant MySql Workbench. De mon point de vue, une base de donnée bien conçue et bien pensée permet déjà d'avoir 70% du travail de fait, et évite de se taper des modèles (dans le MVC) d'une complexité pharaonique.


J'ai l'impression que dans doctrine avant même de faire la BDD, il faut bien avoir en tête son modèle objet. Ainsi, quand on créé une table, il faut immédiatement se poser la question de quel module elle permettra de générer, et donc quelles sont les infos qu'on veut voir apparaitre dans ce module. Si il y a des infos provenant d'autres tables qu'on veut voir apparaitre dans ce module, le mieux est d'attacher ces tables à la table principale avec une relation 1:1, et donc de générer une clef étrangère dans la table principale, permettant ainsi d'obtenir immédiatement toutes les méthodes permettant de récupérer ces infos (en jouant ensuite avec le __toString() pour ramener les infos voulues).

Ma première question est : existe-il un 'truc' du même type pour générer immédiatement un maximum de méthodes pour les relations 1:n ? J'ai l'impression que le recours au vue serait approprié.

Prenons un exemple concret :

Soit un blog avec une table article à partir de laquelle on va générer deux modules : un pour afficher tous les articles paginés avec des métas infos du type vote et nombre de commentaires ; et un autre permettant d'afficher un article en particulier avec tous ses commentaires.

Les tables article et vote sont liées par une relation 1:1 (1 image correspond à une note), aucun problème, on place une clef étrangère id_vote dans la table article. Par contre, chaque article a plusieurs commentaires. Or, on veut afficher le nombre de commentaires sur l'affichage principal et tous les commentaires sur l'affichage d'un article en particulier. En php, c très facile à faire, soit.

Ma question est : comment créer la bdd de manière optimale, de façon à ce que la génération des modèles et des modules produise immédiatement toutes les méthodes voulues (pour les 1:1, c ok, reste les 1:n) ?

De prime abord, j'ai l'impression que l'idéal serait de créer une vue nb_commentaires associant à chaque article le nombre de commentaires associés (avec un select count), et d'associer en clefs étrangère sur la table article l'id adéquat sur cette vue nb_commentaire. (bref, on réduit la relation 1:n à une relation 1:1)

Mais, quid de la génération automatique de la méthode permettant d'afficher tous les commentaires associés à un article ? j'ai l'impression que ce n'est pas faisable (bref qu'on est obligé d'ajouter manuellement la méthode allant chercher tous les commentaires d'un article dans la classe article)...

D'après vous, existe-t-il un moyen d'organiser la BDD de façon à ce que la méthode allant chercher tous les commentaires associés à un article soit générée automatiquement lors de l'opération 'symfony doctrine:build-model' ?

[Michel Rotta]

Tu as deux approches, toutes les deux respectables.

La première qui est basée sur la base de données, les procédures stockées et les vues. C'est une très bonne approche. Elle est compatible avec doctrine et son modèle, il faut juste faire coïncider les classes et les vues (bon, j'ai jamais essayé, mais cela devrait marcher). L'avantage au niveau performance est certains. L'inconvénient est de limiter à un type de base (impossible d'avoir l'application en MySql, sauf pour un petit client qui souhaiterait un sqlite, et un autre qui n'utilise qu'Oracle)... L'autre inconvénient est d'avoir à maîtriser au moins deux langages, le php et le sql transactionnel (voir plusieurs, ils ne sont pas tous exactement).

La deuxième est basée sur le modèle objet de l'ORM doctrine. 90% est bâti par un schema.yml bien construit, le reste est adaptable par quelques méthodes à modifier ou compléter dans le modèle. Les avantages sont inverses à ceux du précédant.


Pour ce qui est des liaisons, en règles générale, les liaisons 1-1 ne sont pas nécessaires. Elles résultent souvent d'une analyse non optimisées. Bien qu'il puisse arriver que l'on en trouve, elles constitues une minorité dans les liaisons.

Pour les liaisons 1-N qui constituent la majorité des relations dans une base, doctrine est parfaitement adapté à l'accès aux données, même si l'accès n'est pas nécessairement optimisé "naturellement" les performances peuvent être adaptées (en nombre de requêtes) dans un deuxième temps.

Un exemple pour le blog, on va avoir deux tables, celle des sujets et celle des commentaires. Le shema.yml pourrait ressembler à ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
sujet:
  columns:
    objet: string(150)
    texte: string
commentaire
  columns:
    comment: string(200)
    sujet_id: integer
  relations:
    sujet:
      local: sujet_id
      foreign: id
      foreignAlias: commentaires

Un peu d'explications :

• Si on ne définit pas de clef primaire, doctrine s'en charge, de type integer auto-incrémenté.
• Il ne sert à rien de définir les options par défaut
• Pour la relation :
  • local indique le nom du champ local (la table où la relation est définie)
  • foreign indique le nom de la clef de l'autre côté de la liaison, ici id qui est créé automatiquement
  • foreignAlias indique le nom par lequel la relation sera vue de l'autre côté de la relation
  • enfin, le nom de la relation (ici sujet) indique le nom de la table opposée et le nom que cette relation aura dans le modèle objet.

Quelques exemples :

• pour un objet $commentaire, on peut récupérer le sujet (côté 1 de la relation) par $commentaire->getSujet() qui retourne un objet doctrine_record avec le sujet. On peut donc récupérer l'objet du sujet par $commentaire->getSujet()->getObjet().
• pour un objet $sujet, on peut récupérer tous les commentaires avec $sujet->getCommentaires() qui retourne un doctrine_collection des enregistrements des commentaires.

Le seul défaut est que si l'on a 10 commentaires pour un sujet, on va générer 11 requêtes, ce qui n'est pas optimisé ! Ce avec la requête de base de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$sujet = doctrine_querry->from('sujet s')->where('s.id = ?', 1);

Ceci peut fonctionner avec une seul requête en l'optimisant un peu

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$sujet = doctrine_querry->from('sujet s')->leftjoin('s.commentaires c')->where('s.id = ?', 1)

et il n'y a plus alors qu'une requête.