Discussion :

[mbouzouita]

Bonjour tous,

j'ai une application ou je veux utiliser des tables qui se trouve sur plusieur base de donnéé.
à savoir que mon IDE est jdeveloper

merci

[Sebou77]

Mais la question elle est ou ?

[mbouzouita]

ma question est comment utiliser des ejbs pour les pages web JSf qui se mappent sur plusieur bases de données.

car quand j'utilise des ejbs de differents bases , je fais la creation des differents projets(chaque projet pour une base de données).

comment utiliser des requettes ejb ql?peut on faire des jointure pour les tables de differents bases? si oui comment?

merci a tous

[a.snaps]

Tu dois définir plusieur contextes de persistence (et plusieurs pool de connexions).
Pour chaque contexte, tu obtiendras un EntityManager. Et devras opérer sur les deux. J'ignore par contre comment gérer les transactions. J'imagine que si tu as des TransactionManager qui sont JTA, ils se registeront en XA?
Cela n'a rien avoir avec plusieurs ou un seul projet dans ton EDI...

Pour ce qui est des requêtes EJB QL, cela ne change rien. Sauf que NON tu ne pourras pas joindre des tables (par extension, il n'y aura aucun lien entre des graphes persisté dans une ou l'autre DB) de différentes DB.
EJB QL est "traduit" vers le dialecte SQL de ta base de données. Or il n'y pas de possibilité de le faire en SQL non plus...

J'envisagerais de migrer le contenu des différentes DB dans une seule unifiée.

Alex

[mbouzouita]

merci pour tes conseilles, mais j'ai plusieur grands projets, maintenant j'ai une application ou j'utilise jdeveloper et ejb3 et mysql et jsf.

j'ai posé cette question car je vais migrer les applications vers j2ee(ils etaient sur access). et il existe plusieur bases de données "mysql".

et lors de developpement je suis obligé de faire de jointure ou s'il y a un autre solution.et je cherche maintenant des solutions.

et pour la technologies j2ee je ne suis pas un expert mais je me debrouille , j'ai lu plusieur articles sur j2ee et ejb3 et ...je compris que j2ee et EJB3 sont performant et fiable pour le developpement de grande application.

par consequence ces grandes applications , c'est forcement d'utiliser plusieur BD et plusieur serveur d'application et BD.

la question est comment ils font lorsque ils veulent chercher des informations sur plusieur BD?

c'est forcement il y a une solution.....

merci

[a.snaps]

Tu peux utiliser plusieurs base de données pour différents EJB Entity.
Cela implique que tu ai des transaction managers JTA qui supporte le "two-phase commit" et XA, afin qu'une transaction puisse joindre l'autre.
Le problème que j'y vois est autre: Tu ne pourras pas (à ma connaîssance, à voir avec un DBA, Oracle fait des trucs dingues ) avoir des contraintes entre tes bases!
Tu devras en plus avoir une pool de connexions par datasource.
Tu ne peux pas t'en sortir avec une DB? Différents schémas éventuellement! Mais pourquoi plusieur DB? Je n'y vois pas d'intérêts... des 100 de Gb de données ne sont pas un problème aujourd'hui dans une DB!
Alex

[mbouzouita]

est ce tu as une idéé sur JTA? comment l'utiliser pour ce cas ? ou est ce que tu as un document qui explique un peu le fonctionnement de JTA?

je n'ai pas compris "XA" c'est quoi?

et l'utilisation plusieur BD, car l'entreprise a creé plusieur BD mysql et ils travaillent avec et je ne peux pas les modifier.

et pour la decomposition des données en plusieur BD je crois que c'est une bonne ideé dans le cas ou il y a un grand nombre de connection et de transaction et pour la securité et autre c'est presque le meme principe de composition des tables, sinon on fait qlq tables qui regroupe tous les données avec qlq centaine de champs on dit que la base supporte ce genre de table...

la question qui se pose c'est comment ils font les grandes entreprises pour ces applications qui sont distrubuées dans le monde comme MasterCarte et CarteVisa et ....qui utilise la technologie j2ee et plusieur serveur d'application et plusieur base de données et qui sont differents et ....

[a.snaps]

JTA = Java Transaction API.

Il est important tu que comprennes bien la notion de transaction, two-phase commit et de transaction distribuée (XA). Tout ceci ne sont pas des concepts que je considèrerais "facilement accessible".

De plus, je ne sais pas ce qui m'inquiète le plus, ta question ou ta question dans un context MySQL.

et pour la decomposition des données en plusieur BD je crois que c'est une bonne ideé dans le cas ou il y a un grand nombre de connection et de transaction et pour la securité et autre c'est presque le meme principe de composition des tables, sinon on fait qlq tables qui regroupe tous les données avec qlq centaine de champs on dit que la base supporte ce genre de table...

Je n'ai rien compris à ta question/affirmation.

• Point de vue nombre de connexion, je ne vois pas le rapport, que ce soit une seul ou plusieur DB, cela ne change rien! Sauf s'il elles sont sur des machines différentes, mais les clusters DB sont là pour résoudre ce problème.
• La sécurité est une couche à intégrer dans ton application, même s'il elle peut "se propager" vers le serveur et non pas de rapport avec une ou plusieurs base/serveur...
• Le principe de composition de table? Quelques tables avec des "centaines" de champs?! Un autre concept intéressant est la normalisation

la question qui se pose c'est comment ils font les grandes entreprises pour ces applications qui sont distrubuées dans le monde comme MasterCarte et CarteVisa et ....qui utilise la technologie j2ee et plusieur serveur d'application et plusieur base de données et qui sont differents et ....

Je pense que tu confonds le rôle de chaque tiers... Les base de données (à la Oracle) résolvent ce genre de problème. Tu peux répliquer, clusterer, etc ta base. Je sais que DB2 permets de "joindre" des tables de base différente, mais cela est fait avec des Views et sont en lecture seule. Mais à nouveau pour ton application, cela ne change rien, tu te connectes à une seule base et la base fait le reste.
Si toute cette architecture complexe est véritablement utile et/ou incontournable, je te conseillerais de te tourner vers Oracle, IBM ou autre qui se feront un plaisir de t'envoyer quelqu'un qui te vendra l'infrastructure nécessaire... Je ne veux pas être moralisateur, mais pas MySQL
Alex

[mbouzouita]

merci pour vos conseils je vais leur proposer votre offre

merci encore