Discussion :

[anfalsh]

Bonjour,

Je pense à utiliser Symfony pour le refonte d'un projet. Avant de me lancer, j'aimerais avoir votre avis sur la gestion par Symfony de plusieurs bases de données.

J'ai vu qu'il était possible de spécifier plusieurs bases de données à Symfony et de préciser le mapping pour chaque bundle afin de pouvoir accéder à l'entity manager correspondant.

Cependant mon cas est particulier. Je vais essayer de vous expliquer ça simplement.

Je récupère des données d'appareils connecté sur internet, et remplis mes bases de données avec ses informations.
Il y a une base de donnée par marque d'appareil (4 marques = 4 bases). Chaque base de donnée contient une table pour chaque appareil de la marque.
Autrement dit, j'ai 4 bases de données avec plus d'une centaine de tables dans chacune.
Les structures de ses tables sont en grande partie les même, sauf quelques exceptions.

Code :

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

1
2
3
4
5
6
7
8
9
10
 
+ base_1
     - donnees1001
     - donnees1002
     ...
     - donnees1240
 
+ base_2
     - ....
....

Y-a-t-il un moyen de greffer symfony sur cette configuration.

D'après ce que j'ai lu, en cas d'utilisation de plusieurs bases de données, il faudrait créer autant de connexion et d'entity manager que de base de donnée. Cela ne semble pas créer de problème.
Mais concernant le nombre important de table que j'ai, comment vais-je pouvoir récupérer les données en fonction d'un id d'appareil (je rappelle que un appareil = une table). Suis-je obligé de créer une entity par table? Car cela me parait infaisable (plus de 600 tables).

Avez-vous une idée sur la démarche à suivre?

J'espère avoir été clair, dans le cas contraire n'hésitez pas à me demander plus de renseignement.

Merci d'avance.

[Nico_F]

Hello,

Si la structure pour une table est la même dans les quatre bases de données, il serait intéressant de faire le test suivant:

Quatre connexions et quatre entity manager.
Une entity pour une table.
Un seul repository.
Faire un findAll() sur le même repository mais avec les 4 EntityManager différents.

Si tu arrives à récupérer les résultats de chacune de tes tables, il n'y a pas de raison de créer plusieurs entités ou plusieurs repository, et tu peux te lancer dans cette affaire.

Deuxième test :
S'il y a quelques différences pour une même table entre les bases de données, je pense tu es obligé de créer plusieurs entités (quitte à faire une entité de base dont les autres héritent) et donc plusieurs repository également.

Pour ce qui est du nombre d'entités à générer, effectivement 600 serait énorme : la question à te poser est : parmi ces 600 tables, combien vont être utilisées pour des actions de lecture, création, modification ou suppression ? Il y a des chances que certaines tables ne soit utilisées que pour faire les jointures mais dont tu n'as pas besoin de récupérer les résultats dans tes objets. Dans ce genre de cas, il peut être judicieux de passer par des requêtes natives (le DQL requiert l'existence des entités) que tu mappes par la suite à l'aide du ResultSetMapping de Doctrine.
Sur une requêtes qui utilise 10 tables (avec des jointures et des where dans tous les sens) tu n'auras peut-être besoin que de récupérer les données de trois tables. Du coup trois entités peuvent suffire. A toi de voir combien de tables doivent vraiment être transformées en entités.
En poussant le bouchon vraiment plus loin tu peux également envisager de ne pas créer d'entité pour les tables sur lesquelles tu ne feras que de la lecture ou de l'affichage et traiter ces cas là avec un retour sous forme de tableau venant d'une requête native. Ça peut également réduire le nombre d'entités.

Je ne sais pas si tu pousseras l'optimisation jusque là mais ce sont des idées alternatives ou supplémentaires pour ta problématique liée au nombre d'entités à générer.

++