Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1553 connectés 

  FORUM HardWare.fr
  Programmation
  C++

  industrialisation d'outil vba vers c++...

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

industrialisation d'outil vba vers c++...

n°2101865
angie_86
Posté le 16-09-2011 à 16:35:34  profilanswer
 

Bonjour,  
 
avant tout je veux préciser que je ne suis pas une pure développeuse ni informaticienne, mais j'ai de bonnes notions maitrise tout ce qui est base de données, POO, ..., et suis suffisamment débrouillarde :)
 
je voudrais juste obtenir quelques pistes de développements sur un projet sur lequel je travaille en fil rouge depuis 2 ans, voici mon sujet:
 
J'ai développé un outil de simulation pour des sociétés de gestions de portefeuille...
 
cet outil demande de gérer beaucoup de données, dont principalement données de marché, données de résultat de simulation , données comptables, données de calibration de modèle (etc...)
 
au départ je suis partie uniquement en utilisant uniquement des spreadsheets excel(+un peu de VBA)  pour avoir une maquette d'outil,  très dirty (une centaine de feuilles excel quand même)
 
je me suis ensuite dirigée vers un développement VBA sous Access (qui me permet de gérer les données sus-dites dans une base de données ) ... et j'arrive à obtenir un outil robuste....mais je me heurte aux limites d'access et de vba.... (lenteur + limite de stockage + lenteur)....
 
je voudrais industrialiser cet outil pour notamment rendre les calculs(que je faisais en vba)  et l'acces aux données  beaucoup plus rapides(que je faisais avec des recordset, et des requetes sql....)  ....
 
je pense donc que passer en C++ semble être la bonne solution, puisque a priori on peut tout faire avec C++
...:)
 
 
Mon problème est que je ne comprends pas bien comment je peux arriver à manager toutes les données dont j'ai besoin sous C++,  
dois-je conserver un SGBD indépendant (+ puissant qu'access) et conserver mon systeme d'acces aux données via recordset,
 
ou bien développer en C++ ma propre bdd? (ou autre chose encore...?)
 
Par ailleurs, j'aimerais qu'au final ce soit un outil facilement (trans)portable et  facilement instalable .....  
 
je suis ouverte à toute recommandation,
 
Merci pour votre aide,  
 
 
Angie.
 

mood
Publicité
Posté le 16-09-2011 à 16:35:34  profilanswer
 

n°2101875
shaoyin
Posté le 16-09-2011 à 17:06:41  profilanswer
 

Bonjour,
 

angie_86 a écrit :


je pense donc que passer en C++ semble être la bonne solution, puisque a priori on peut tout faire avec C++
...:)


Pour l'instant, ca ne me choque pas !
 

angie_86 a écrit :


Mon problème est que je ne comprends pas bien comment je peux arriver à manager toutes les données dont j'ai besoin sous C++,  
dois-je conserver un SGBD indépendant (+ puissant qu'access) et conserver mon systeme d'acces aux données via recordset,


Si tu dois gérer beaucoup de données, alors oui, tu as tout intérêt à utiliser un SGBD. En général, avec les API qui les accompagnent, c'est un jeu d'enfant de s'interfacer. (Enfin, ca dépend aussi des SGBD...)
Après, tout dépend de ce que tu dois faire avec ces données, de la complexité de leurs relations...
 

angie_86 a écrit :


ou bien développer en C++ ma propre bdd? (ou autre chose encore...?)


Y'en a qui ont essayé, ils ont eu des problèmes !  ;)  
:sweat: A moins que tes besoins ne soient extrêmement simples, c'est une très mauvaise idée de réinventer la roue (et les bugs qui vont avec)...  
 

angie_86 a écrit :


Par ailleurs, j'aimerais qu'au final ce soit un outil facilement (trans)portable et  facilement instalable .....  


Il existe des outils pour gérer l'installation, cet aspect là n'est pas forcément un problème. Par contre, qu'entends-tu par "(trans)portable" ???  

n°2101882
angie_86
Posté le 16-09-2011 à 18:17:17  profilanswer
 

bonjour shaoyin et je te remercie pour de t'interesser à mon sujet,  
 
ok je ne développerai pas ma propre Bdd....(au moins j'évite ca ..merci !)  
mais j'ai vraiment beaucoup de données à gérer notamment de données comptables (+ tout ce qui est données de marché.... )  
 
En gros mon outil pour l'instant nécessite d'avoir une grosse base de données:
pour l'instant sous acces j'ai une cinquantaine de tables:  
- une 30aine de tables servent à enregistrer ce que j'appelle les inputs de la simulation (données de marché,  portefeuille sur lequel(s) j'effectue la simultaion, données de simulation (type de gestion effectué sur le portefeuille..))  
- une vingtaine de table servent à enregistrer ce que j'appelle les outputs de la simulation c'est à dire les  résultats... (en gros état du portefeuille date par date apres chaque opération (achat/vente),  perf réalisées etc.. )
 
 ca fonctionne comme ca: entre mes tables inputs et table outputs je fais pleins de calculs ou je simule des achats et des ventes  avec plein de contraintes ,je fais des calculs de vl ou se genre de truc.. sur un horizon de temps défini en amont...  
 
 pour cela j'ai concu une bd relation type entité relation... que j'ai sous access et que je pense peut etre facilement reproduit sous n'importe quel  
SGBD......
 
pour arriver à un résultat satisfaisant j'ai besoin de gagner beaucoup beaucoup de temps sur les calculs effectués et surtout lorsque j'interroge ma bd avec des requetes(et pourtant j'ai optimisé tout ca sous access avec des index et tout ca...:)
 
si je pouvais rester comme ca, ca serait idéal.. mais il me faut une technologie plus puissante...(parcque j'ai des idées pour faire beaucoup beaucoup plus de développements dessus mais j'aimerais d'abord être bien sur une première version beta 0.01 :)   )
 
 
pour les calculs il est clair qu'avec C++ je vais gagner en temps.... mais pour interroger une bd je sais pas quoi choisir et il faut que je sois absolument efficace sur les deux plans ....  
ou alors peut-être une autre méthode s'impose?
 
 
par ailleurs quand je dis qu'au final il faudrait que ce soit facilement transportable ca veut dire avec mes mots à moi que si je veux installer ce truc sur un nouveau poste je dois pas avoir à installer un milliards de trucs et qu'en qqs minutes maximum ce soit fait... mais bon à la limite je verrais ca plus tard....
 
merci encore pour ta réponse!
et merci d'avance pour les autres réponses :)
 
Angie
 
 

n°2102017
Joel F
Real men use unique_ptr
Posté le 18-09-2011 à 08:59:27  profilanswer
 

le truc serait en C++ de fire des requetes via un bidning SGBD quleconque (y a plein de bibliotheque qui permettent d'attaquer des SGBD depuis C++), remplir un tableau C++ du resultats de ces requetes et effectuer tes calculs.
 
C'est une structure classique, ca tourne plutot bien.

n°2102025
gilou
Modérateur
Modzilla
Posté le 18-09-2011 à 09:55:00  profilanswer
 

Perso, vu qu'elle est dans un environnement windows, et qu'elle a pas encore vraiment choisi un langage de dev, je pense que C# (ou Visual Basic, puisqu'elle a fait du VBA) et son extension LINQ serait peut être plus simple a mettre en place pour elle.
A+,


Message édité par gilou le 18-09-2011 à 10:02:46

---------------
There's more than what can be linked! --    Iyashikei Anime Forever!    --  AngularJS c'est un framework d'engulé!  --
n°2102049
Joel F
Real men use unique_ptr
Posté le 18-09-2011 à 11:32:25  profilanswer
 

ouais y a LINQ aussi bien vu ^^

n°2102140
angie_86
Posté le 19-09-2011 à 09:40:52  profilanswer
 

ok merci pour toutes ces pistes,  
 
je vais essayer de creuser .....:)


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  C++

  industrialisation d'outil vba vers c++...

 

Sujets relatifs
[POO] Héritage vers Base de données relationellecopier de excel vers word
faire un lien vers une vidéo pour la telecharger ?[analyse] transformer MCD vers UML
[Lazarus]drag and drop vers une autre application[Wiki] Créer des liens externes vers un serveur
Lien vers nouvelle page si bonne réponseConvertir une date au format JJMMAAAA vers le format JJ/MM/AAAA
comment transférer une variable vers une autre pageOVH redirection mondomaine.fr vers www.mondomaine.fr
Plus de sujets relatifs à : industrialisation d'outil vba vers c++...


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR