plusieurs resultats d'une requete en une

Avec une fonction java, je fais une requete dans une base de données.
Mon problème est que j'ai une jointure one to many a un endroit ce qui des fois
j'ai plusieurs lignes:
pour un num personne on peut avoir plus adresses

Code:

---

1 2 3 4 5 6 7 8

select p.name, co.adresse from personne p , coordonnee co, where p.num=co.num

---

les résultats de la requête sont mis dans un bean.
Ma question est de savoir s'il y a pas un moyen au lieu d'avoir plusieurs ligne d'avoir une seule avec la concaténation des adresses.
J'ai pensé a des tableaux mais je ne sais pas comment le mettre en place.

Les outils qui font du mapping relationnelle - Objet sont souvent regroupés sous
l'acronyme ORM (Object Relation Mapping).

Des frameworks comme hibernate ou JDO permettent de charger des objets à partir de requête sql. (vois aussi la norme JPA)


J'ai aussi le cas d'une personne qui peut avoir plusieurs adresses

dans mon cas, j'ai trois objets. un pour la personne, un pour l'adresse, et un pour la relation personne-adresse (car nos adresses sont typés et cet objet de relation est très pratique pour les recherches)

A+

Citation:

---

Envoyé par oca

dans mon cas, j'ai trois objets. un pour la personne, un pour l'adresse, et un pour la relation personne-adresse (car nos adresses sont typés et cet objet de relation est très pratique pour les recherches)

---

Juste par curiosité : comment l'objet de relation facilite les recherches ?

arff... oui, simplifie n'est pas vraiment le bon mot... j'aurais plutôt du utiliser "centralise" ou autre chose... ce que je voulais surtout dire, c'est que mon objet relation est un objet "fort" dans mon modèle, mais c'est vrai qu'il ne simplifie pas grand chose....

Citation:

---

Envoyé par oca

arff... oui, simplifie n'est pas vraiment le bon mot... j'aurais plutôt du utiliser "centralise" ou autre chose... ce que je voulais surtout dire, c'est que mon objet relation est un objet "fort" dans mon modèle, mais c'est vrai qu'il ne simplifie pas grand chose....

---

C'était vraiment par curiosité... Mais du coup, ton explication me titille encore plus :lol: : En quoi cette objet de relation est un objet fort dans ton modèle ? (c'est vraiment de la curiosité de comment les autres codes, c'est que je vois vraiment pas le rôle de cette object relation dans une structure de données)

J'ai besoin de cet objet relation car mes adresses sont typés

j'ai donc un objet relation qui ressemble à cela :

Code:

---

1 2 3 4 5 6 7

public class Relation { int idRelation; int idPersonne; int idAdresse; int type; }

---

du coup, c'est la relation qui "connait" le tiers et l'adresse, c'est pour cela que je considère mon objet relation comme un objet fort. Le tiers lui, ne connait pas l'adresse directement.

Mes recherches se font alors avec qqch du genre :

Adresse a = relationService.findAdresseForTiers(idPersonne,type);

Après, il est toujours possible d'avoir des méthodes de commodités du genre :

Adresse a = personneService.findDefaultAdresse(idPersonne);

mais d'un point de vue modèle, c'est ma relation qui connais les autres objets.

Je ne dis surtout pas que c'est la seule ou la meilleure façon de faire, mais c'est comme cela chez nous ;)
A+

Citation:

---

Envoyé par oca

J'ai besoin de cet objet relation car mes adresses sont typés

---

Ok, bonne justification de l'utilité de l'objet relation.

Citation:

---

Je ne dis surtout pas que c'est la seule ou la meilleure façon de faire, mais c'est comme cela chez nous ;)

---

En fait, sur mon projet précédant, en suivant l'évolution dans le CVS, j'avais vu une structure de ce type avec un objet relation (mais pas typé). Cette structure avait été remplacé (par un autre codeur) par un ensemble de structure (hashmap dans tous les sens) pour executé les recherches et économiser les instanciations des objet relations. J'avoue que la relecture du code dans le second cas est plus rude. Je suis resté sur l'intérogation de l'efficacité d'un code sur l'autre. Mais comme tu dis, il y a plusieurs façon de résoudre un problème ;)

Merci en tout cas !

Note : Désol pour le sujet principal, mais le cas d'utilisation était interessant...