[DAO] Jointure entre deux tables

[Rodrik]

Voilà je travaille sur l'architecture de mon site et j'en suis à l'épineux problème des DAOs. Je voudrais partir sur une base aussi cohérente que possible, aussi j'ai besoin de vos conseils

Mon architecture est un pseudo MVC. Pseudo car en réalité Vue et Contrôleur ne sont pas objets: le contrôleur est du code procédural qui récupère les bonnes données et inclue la vue correspondante, suivant la situation. De ce côté ce n'est certes pas très catholique mais ça ne me pose pas de problème.
Mon modèle lui est parfaitement objet. Il est composé de classes métiers, qui interagissent avec les DAO au moyen de TO (Transfert Objet, ou DTO ou VO si vous préférez). Jusque là pas de problème. Ce qui m'ennuie c'est que je n'ai pas trouvé de moteur de DAOs qui me convienne en PHP, je dois donc tout me taper à la main.

Et là question: comment gérer les requêtes à base de jointures. Ou plutôt, où les gérer?

Prenons un exemple simple, on a une table "joueur" et une table "ville", avec une clé étrangère id_joueur dans "ville". J'ai un DAO par table, normal. Disons que je veux récupérer la liste de tous les joueurs associés avec le nom et le lieu de leur ville (infos dispos dans la table ville). Qui se charge de cette requête?
Le DAO de la table "joueur"? le DAO de la table "ville"? Un nouveau DAO spécifique à cette table virtuelle (jointure)?
Dans tous les cas je devrai créer un TO spécifique.

Voilà je suis un peu perdu, sans le support d'un framework qui se charge des DAOs. Je me doute bien que la réponse qui vous vient est "sers toi d'un framework", mais si j'ai décidé de ne pas en utiliser un, c'est justement pour progresser sur ce type de questions techniques ^^

[Allwise]

Moi je dirais que ça dépend, et que ta requête devrait être dans le modèle de l'entité la "plus importante" dans la dite requête. Si ta requête se concentre davantage sur le joueur et que la ville est une caractéristique du joueur, je mettrais la requête dans le modèle joueur.
Une requête qui aurait pour objet de récupérer toutes les villes et le nombre de joueurs dans chacune d'elles, je l'aurais mise dans le modèle ville par contre.

Sinon, quand tu dis

on a une table "joueur" et une table "ville", avec une clé étrangère id_joueur dans "ville".

Ce serait pas plutôt :

on a une table "joueur" et une table "ville", avec une clé étrangère id_ville dans "joueur".

?

[Rodrik]

Merci pour cet élément de réponse, ce que tu proposes est aussi ce que je trouvais le plus logique, mais je préfère confronter les avis ^^

Pour la clé en fait c'est les deux actuellement, mais vu que ça risque de ne pas rester un lien 1:1 je vais devoir faire sauter la clé étrangère dans la table "joueur" je pense.

[christouphe]

j'aurai plutôt fait une table de jointure car d'après ce que tu dis, c'est une relation 1 - N (plusieurs joueur peuvent se trouver dans une ville donnée)

Avec une table:

joueur_ville (id,id_joueur,id_ville)

Et là tu aurais un DAO supplémentaire qui s'occuperait de te renvoyer les joueur présents dans une ville.

[Rodrik]

Vu que ce sera une relation 1..n, créer une table intermédiaire risque de multiplier les jointures. C'pas simple tout ça...

J'arrive pas vraiment à déterminer ce qui est le mieux, je vais devoir faire des tests ...

[Allwise]

Un joueur ne peut se trouver que dans UNE ville, c'est une relation 1:n, non pas n:n, donc inutile d'ajouter une table intermédiaire ( prévue pour les cas n:n )

[Melimelo]

je suis de l'avis de Allwise

[Morningkill]

Tu as beaucoup de villes ?

Parceque si tu en as peu (et "constantes"), pour ma part, a ce stade de ce que j'en sais, je mettrai en "cache serveur" une association du type (idville, nomville), et quand j'ai besoin d'afficher le nom d'une ville a partir d'un joueur, faire un truc du style NomVille=Villes[monjoueur.ville_id];

Histoire d'optimiser. Aprés, l'optimisation prématurée est la mère de tout les vices..

Tant qu'a faire, tu peux même mettre NomVille en propriété de ton objet joueur.

(sinon, je suis d'accord, relation 1..N, et une clé "joueur_id" dans "ville" ne peut pas représenter "ce joueur est dans cette ville")

[Rodrik]

En fait c'est la situation inverse: un joueur possède une ville, mais peut éventuellement en posséder plus d'une. Une ville n'a donc qu'un seul joueur dans tous les cas.

Mais effectivement un peu de redondance entre les tables permettrait d'alléger les requêtes les plus courantes.

Merci pour vos conseils, je vais cogiter là dessus.