Discussion :

[imhotep_zr7s]

Bonjour,

J'ai deux DataSets Personne et Adresse.
Dans le DataSet Personne je récupére le Nom, Prénom, et un IdAdresse.
Je souhaite pouvoir récupérer l'Adresse en passant au DataSet Adresse l'IdAdresse récupéré sur le DataSet Personne le tout dans le même report.
D'avance merci de votre aide.

@+

[BiM]

Bonjour,

Pour cela il faut faire de l'imbrication de DataSet mais c'est déconseillé en terme de performances. Il aurait mieux fallu un DataSet comprenant toutes les informations dans ce cas.

[birt1976]

Pour le moment, je ne sais pas faire ça, mais je vais étudier la question.

Par contre, tu imbriques des data-set et surement par la suite des tables, sâches que les performances de BIRT en sont fortement réduites.

Si tu peux, il faut tout faire dans un seul data-set.
Et là, ça n'a pas l'air d'être très dur de faire une jointure simple.

[BiM]

Le mot jointure m'a fait tilté. Fait un JointDataSet, ce sera plus efficace et plus propre.

[imhotep_zr7s]

Merci pour vos réponses. La réponse est malheureusement celle que j'attendais. J'ai essayé avec des join data set mais les temps de réponses sont vraiment ca-tas-tro-phiques !!
Donc dommage, vais être obligé de tout faire dans un seul data set et du coup je perd en modularité. :aie :
Dommage !

[erwan.bodere]

Tu peux faire un dataset Personne, un dataset Adresse et un dataset AdressePersonne. Tu ne perds rien en modularité ainsi et de plus tu gagneras en terme de performances.

[birt1976]

Tu peux faire un dataset Personne, un dataset Adresse et un dataset AdressePersonne. Tu ne perds rien en modularité ainsi et de plus tu gagneras en terme de performances.

Bonne idée, sauf que tu perdras tout de même un peu en performance.
Car tu vas ramener 2 fois plus d'enregistrements que si tu avais une seule requête.
Et ce n'est pas si modulaire puisqu'en général, 1 édition = 1 rptdesign.
Donc j'aurai tendance à dire 1 edition = 1 dataSet sauf cas particulier.

Après, si tu veux de la performance, il faut absoluement que tu ne fasse qu'un seul data-set, par contre ça oblige à être assez malin en SQL.

Si la requete SQL est simple a ecrire autant faire qu'une requete, t'auras tout à gagner.

Et si elle est compliquée, tu t'en sortiras p-e pas à l'écrire.
Mais si tu prends un peu de temps à chercher et que tu t'en sors, tu y gagneras enormément.

Moi, dès fois je préfère faire une requête complexe qui ramène un peu trop d'enregistrements quitte à les masquer plutot que de faire plein de requetes assez simples qu'il faut combiner.
On préfère la performance quitte à faire un peu complexe.


Merci, Imotep j'ai testé les join data set.
Pour le moment, je suivai juste les recommandations de la boite.
Là au moins, j'ai vu le pourquoi de cette recommandation.

Enfin vu ce que propose les JOIN data set, je pense qu'on peut facilement les oublier car ils ne proposent pas plus qu'une requete SQL.

[erwan.bodere]

Bonne idée, sauf que tu perdras tout de même un peu en performance.
Car tu vas ramener 2 fois plus d'enregistrements que si tu avais une seule requête.

Par forcément, tu peux stocker ces 3 requêtes dans une librairie et en utiliser que un dans un rapport et les 2 autres dans un autre rapport. Si on doit ramener les informations des personnes et des adresses, et surtout si il y a pour une personne une et seule adresse, il vaut nettement mieux utiliser un seul dataset.

Et ce n'est pas si modulaire puisqu'en général, 1 édition = 1 rptdesign.
Donc j'aurai tendance à dire 1 edition = 1 dataSet sauf cas particulier.

Faux. J'ai pas mal de rapports et j'ai aucun qui décrivent ce type de comportement. Mes rapports utilisent en moyenne une trentaine de datasets, plusieurs datacubes et une bonne cinquante de composants.

Après, si tu veux de la performance, il faut absolument que tu ne fasse qu'un seul data-set, par contre ça oblige à être assez malin en SQL.

Complètement d'accord. Je ne pense pas que cela soit très difficile de faire une jointure entre la source (table, vue, ..) personne et la source adresse. Il ne s'agit ici que d'une simple jointure.

Merci, Imotep j'ai testé les join data set.
Pour le moment, je suivai juste les recommandations de la boite.
Là au moins, j'ai vu le pourquoi de cette recommandation.

Enfin vu ce que propose les JOIN data set, je pense qu'on peut facilement les oublier car ils ne proposent pas plus qu'une requete SQL.

Perso, je conseille uniquement d'utiliser les join datasets pour fusionner des données provenant de sources différentes (bdd, xml, csv, ...)

[birt1976]

Je suis tout à fait d'accord avec toi, Erwann.
Et je t'applaudis, je suis bien content de voir qu'on a un EXPERT de BIRT.

Par contre je suis un peu surpris de ta phrase

J'ai pas mal de rapports et j'ai aucun qui décrivent ce type de comportement. Mes rapports utilisent en moyenne une trentaine de datasets, plusieurs datacubes et une bonne cinquante de composants.

Car tout de même, tu devrais avoir des éditions basiques pour certaines tables de ton application.

J'imagine la tête de tes éditions.
Elles ne rament pas trop avec l'utilisation de tous ces outils ?

NB: je suis vraiment un petit joueur à coté.

[BiM]

Je n'ai également que des éditions avec plusieurs DataSet car elles sont très complexes ou offrent des présentations modulables. Je crois que tu penses comme ceci parce que tu n'as encore assez explorer les possibilités de BIRT

[birt1976]

Je n'ai également que des éditions avec plusieurs DataSet car elles sont très complexes ou offrent des présentations modulables. Je crois que tu penses comme ceci parce que tu n'as encore assez explorer les possibilités de BIRT

Bien possible.
J'en suis qu'au début.

Je suis de l'ancien temps où on faisait ses éditions UNIQUEMENT par programmation.
Aussi, je ne connais pas forcement tout ce qu'y peut se faire avec un outil de génération d'édition, c'est le 1er que j'utilise.
Mais le FORUM est là.


Ma plus grosse requête possède une dizaine de liens en inner ou outer join avec des restrictions like, exist etc...


Pour la modularité, on est en cour de recherche.
Pour le moment, on préfère faire plus d'édition que de surcharger une édition de multitude de data-set.


Et pour le moment, il y a certaines éditions que je n'arrive pas à faire.
D'ailleurs, je n'ai eut aucune réponse à certaines de mes questions malgré que j'indiquais un début de possibilité.

Pour ces éditions, pour le moment, aucun collègue n'a encore trouvé de solution.