Discussion :

[Afaf001]

Bonjour à tous,

Nous devons lire des données (massives) d'un fichier excel, faire de nombreux calculs sur ces données, afin d'afficher des graphes sur des interfaces qui doivent être interactives, offrant la possibilité à l'utilisateur de saisir des paramètres dépendamment desquelles les graphes vont changer de comportement.
Actuellement tout le boulot se fait avec du excel et du vba, mais le système devient de plus en plus lent à mesure que la taille des données augmente. Des fois le système se plante carrément.
Je me demande bien quelle serait la meilleure technologie, en terme de performance (bien évidemment la qualité des algorithmes joue un rôle) que je pourrait utiliser pur répondre à ce besoin.

Merci énormément pour vos retours

[fatbob]

C'est sûr qu'excel, ça n'est pas vraiment fait pour gérer de gros volumes de données.
Déjà Access sera probablement un peu mieux tout en gardant une certaine facilité de programmation.
En effet, si les volumes de données sont importants, une base de donnée est nécessaire.

Après, pour quelque chose de plus sérieux et évolutif, il faudra passer à un vrai développement pas forcément simple si les interfaces sont complexes. Pour les graphes, en particulier, il faudra faire attention aux bibliothèques disponibles...
Sinon, le choix des langages dépendra d'un certain nombre de paramètres du genre "combien d'utilisateurs sont susceptibles d'utiliser l'application simultanément", "Comment veut-on déployer l'application (web, client serveur, standalone)", "faut-il interagir avec d'autres applications ?"
Pour un développement plus simple et pas trop éloigné de ce qui peut se faire avec access, on pourra utiliser delphi (ce n'est pas la même chose quand même, déjà parce que le langage est pascal et pas vba)
Sinon, les possibilités sont multiples... mysql (ou postgresql)/Php/javascript, python...

[Igloobel]

Bonjour,

j'ajouterai à ce qu'a dit fatbob (auquel j'adhère) qu'il existe aussi des logiciels type AGL (Atelier de Génie Logiciel) comme WINDEV par exemple. Il est assez facile à appréhender et très puissant (il connait en natif une grande quantité de base de données). Bien évidemment c'est cher à l'achat mais il génère des exécutables et c'est pratique.

Maintenant si c'est le coût qui prime la combinaison (MySQL / Php) est à mon avis la meilleure. C'est une solution entière gratuite avec une communauté d'entraide importante. mais il nécessitera un apprentissage qui peut s'avérer long et difficile.

Bonne journée à tous

[78chris]

Bonjour

Il faut considérer 2 aspects :

• d'une part le volume de données où les SGBD sont une bonne solution
• d'autre part la complexité des calculs et les graphiques
  
  • si les calculs ne sont pas trop complexes, la base de données peut le faire, ou en réaliser une partie. Il restera les graphs à la charge d'Excel ou outil spécifique
  • sinon, il n'est pas sûr que déporter les données dans une base mais opérer les calculs dans Excel améliore tant que cela les temps de réponse

Il faut donc analyser de façon fine afin de voir si un couplage Access / Excel (ou autre SGBD) permettra ou non de résoudre.

[Igloobel]

Bonjour

Il faut considérer 2 aspects :

• d'une part le volume de données où les SGBD sont une bonne solution
• d'autre part la complexité des calculs et les graphiques
  
  • si les calculs ne sont pas trop complexes, la base de données peut le faire, ou en réaliser une partie. Il restera les graphs à la charge d'Excel ou outil spécifique
  • sinon, il n'est pas sûr que déporter les données dans une base mais opérer les calculs dans Excel améliore tant que cela les temps de réponse

Il faut donc analyser de façon fine afin de voir si un couplage Access / Excel (ou autre SGBD) permettra ou non de résoudre.

C'est juste mais ACCESS sait parfaitement faire des TCD et des graphique directement sans l'aide d'Excel.

[78chris]

Bonjour

C'est juste mais ACCESS sait parfaitement faire des TCD et des graphique directement sans l'aide d'Excel.

Plus à partir de la version 2013 : donc même si possible avec 2010, privilégier l'avenir...

Et je ne parlais pas seulement de calculs statistiques mais d'éventuelles formules balaises...

[Igloobel]

...
Plus à partir de la version 2013 : donc même si possible avec 2010, privilégier l'avenir...

Et je ne parlais pas seulement de calculs statistiques mais d'éventuelles formules balaises...

Eh M...... je savais pas qu'en 2013 il l'avais viré (j'ai pas au dessus de 2010)

...... Dooooommmmmmaaaaaggggeeeee ........

pour garder une compatibilité avec les versions précédentes ils auraient mieux fait de le laisser

merci Chris pour l'info

[78chris]

Re

Eh M...... je savais pas qu'en 2013 il l'avais viré (j'ai pas au dessus de 2010)

...... Dooooommmmmmaaaaaggggeeeee ........

pour garder une compatibilité avec les versions précédentes ils auraient mieux fait de le laisser

merci Chris pour l'info

Je l'avais aussi indiqué là au #7 http://www.developpez.net/forums/d15...access-2013-a/ : eh oui la logique MS est parfois curieuse...