Discussion :

[VironFlo]

Bonjour à tous,

j'aimerais développer un programme de gestion pour ma société.


Pour le moment, le listing est repris dans un fichier excel mais on encode chez le client après l'intervention
avec comme information:
_ Nom et prénom
_ Adresse
_ numéro de téléphone
_ nombre d'intervention
_calcul tva et prix total.

J'aimerais pouvoir remplir les données automatiquement par rapport à la tournée de la journée. En utilisant excel comme base de donnée.

J'ai surtout développer avec unity (J'ai suivis une bachelier en conception de Jeux-vidéo) et je ne sais pas vers quelle solution m'orienter pour commencer le programme qui serait développer sur Windows?

Par la suite, j'aimerais utiliser d'autres fonctions comme l'api de google map sur une application qui serait connecté à la "station principal", et qui contiendrait quelques informations supplémentaires comme une photo, remarque.

ps: ceci est mon tout premier message, j'espère avoir été assez clair, comme ma demande est assez précise, j'ai préféré faire une nouvelle discussion.

Merci d'avancer pour le temps que vous me consacrerez,
flo

[dalfab]

Bonjour et bienvenue

Il doit exister des tas de moyens pour résoudre ton problème, mais je doute fort que le C++ soit une bonne idée pour cela. Aurais-tu commis une erreur de forum?

La conception c'est important, mais ça inclut aussi le choix du "bon" langage. Peux-être qu'ici l'utilisation directe de formules Excel pourrait suffire, avec ajout possible de quelques macros.
On peut tout à fait avoir une feuille Excel qui va chercher les informations dans un autre fichier.

[koala01]

Salut, et bienvenue sur le forum.

Je ne crois sincèrement pas que excell (qui n'est jamais qu'un tableur) soit la solution la plus adaptée à ton problème. Une (vraie !!!) base de donnée serait sans doute bien plus intéressante.

L'un dans l'autre, si l'utilisateur est unique, quelque chose d'aussi simple que SQLite pourrait sans doute faire l'affaire, mais, à termes, quelque chose de plus "centralisé", permettant à plusieurs personne de travailler en même temps pourrait s'avérer des plus utiles

Quant à l'interface graphique (et l'intération à la base de donnée), le framework Qt devrait te permettre de faire exactement ce que tu veux (y compris de faire une version de ton application pour smartphones / android )

Ceci étant dit, si tu es déjà habitué à utiilser Unity, tu auras peut-être plus facile à coder ton application en C#, car tu partirais sur un langage connu, et que C++ est quand même un langage particulièrement complexe à apprendre (même si ca rajoute une corde à ton arc)

[VironFlo]

Tout d'abord merci pour vos réponses
en faite j'ai commencé à apprendre en c++ avant de me mettre au c Sharp (même si je n'ai pas poussé très loin le c++).
J'ai répondu dans cette section car je pensais qu'il fallait que je m'oriente vers ce langage.
Je ne connais pas bien excel, mais en effet, par la suite je voudrais complexifier le programme

Il y'aura plusieurs utilisateurs, à court termes, au moins trois, mais selon la croissance de l'entreprise, il pourrait y en avoir d'autres. Peux-ton travailler dans cette optique avec SQlite?

Pour aller un peu plus loin^^ ça serait bien que la base de donnée soit sur un serveur, un ordinateur recyclé dans mon cas.

[koala01]

Tout d'abord merci pour vos réponses
en faite j'ai commencé à apprendre en c++ avant de me mettre au c Sharp (même si je n'ai pas poussé très loin le c++).
J'ai répondu dans cette section car je pensais qu'il fallait que je m'oriente vers ce langage.

Pourquoi crois tu devoir t'orienter vers ce langage en particulier

Après tout, ce n'est pas comme si chaque demi seconde passée à attendre coutait des vies

Je ne connais pas bien excel, mais en effet, par la suite je voudrais complexifier le programme

Donc, il faut d'office oublier excel pour ces deux raisons

Il y'aura plusieurs utilisateurs, à court termes, au moins trois, mais selon la croissance de l'entreprise, il pourrait y en avoir d'autres. Peux-ton travailler dans cette optique avec SQlite?

SQLite pourrait faire partie de la solution pour le cas où les utilisateurs n'auraient (temporairement) pas accès au serveur sur lequel serait la base de donnée centralisée (quand il sont au fin fond de la brousse ou chez le client, par exemple ) car cela permettrait de sauvegarder les informations "en attente de synchronisation", mais cela pourrait compliquer pas mal les choses, pour, justement, arriver à synchroniser ces données.

Mais, de fait, comme on l'a déjà dit tous les deux, quelque chose de plus centralisé serait surement préférable.

Par chance, Qt fournit "tout ce qu'il faut" pour travailler avec des bases de données

• MySQL / MariaDB
• PosGreSQL
• MsSQL
• Oracle
• IBM DB2

Comme tu peux le voir, il y en a pour tous les gouts et pour toutes les bourses

L'idéal, ce serait de s'assurer que l'utilisateur ait toujours un accès au serveur (avec la 4G et autres technologies, il devient de plus en plus facile de garantir ce genre d'accès )

Pour aller un peu plus loin^^ ça serait bien que la base de donnée soit sur un serveur, un ordinateur recyclé dans mon cas.

Et je présume que tu aimerais autant, dans un premier temps du moins, faire l'économie d'une licence pour l'OS et pour le serveur de base de données que tu installera dessus, me trompes-je

Je verrais bien une installation de type "serveur" minimale à base de debian (ou autre linux), à base de MariaDB (la version complètement libre de MySQL ou de PostGreSQL pour commencer

Après, il faut garder en mémoire que ta base de données va représenter l'âme et le sang de ton entreprise : si tu la perd, tu perd toute l'histoire de ton entreprise, et tu risques d'être fameusement dans le caca à la fin de l'année

Si je comprend le souhait de recycler un vieux PC, je me sens obligé de te mettre en garde sur l'absolue nécessité d'avoir des sauvegardes régulières et de protéger ces données presque mieux que la manière dont tu protège ce qu'il y a (ou pas...) entre tes jambes

Et ce sera d'autant plus vrai si ton serveur est connecté à internet, ne serait ce que pour permettre aux utilisateurs itinérants de travailler, si bien que, alors que je plaidais plus haut pour essayer de garantir l'accès au serveur en itinérance, l'aspect "sécuritaire" de la chose plaiderait sans doute pour que ce serveur soit au pire dans une zone démilitarisée pour éviter que "n'importe qui" n'aille y foutre le bordel

A moins, bien sur, que tu ne connaisse un spécialiste en sécurité qui puisse faire en sorte de t'aider à "blinder les accès au serveur"

Tout cela pour dire qu'il y a des solutions qui existent, mais que certains choix doivent être fait avant de pouvoir s'orienter vers l'une ou vers l'autre

On est sans doute d'accord pour dire que la solution passera par une base de données (quoi que, avec NoSQL, on pourrait aussi arriver à quelque chose de pas mal ) mais, pour le reste, il s'agira surement d'avoir bien réfléchi à la structure de ton entreprise et à la place que prendra ton serveur dans celle-ci avant de te décider

[Christophe]

Comme c'est quand-même relativement orienté bureautique, Access serait un bon candidat. Tu pourras envisager une base autonome quand tu sera en déplacement et qui se synchronise avec la base principale au bureau : ce sera le point de difficulté.

Mais je dirais que tout dépend de la volumétrie. Mais vu la demande, je suppose qu'elle est faible.

[koala01]

Comme c'est quand-même relativement orienté bureautique, Access serait un bon candidat.

Oui, mais, access n'est pas un serveur de base de données relationnelle... c'est un système très similaire à SQLite (avec toute la partie graphique qui va bien, je te l'accorde), d'avantage prévu pour une utilisation locale; on pourrait presque dire "embarquée dans l'application"

Dés qu'il s'agit d' avoir plusieurs utilisateurs qui travaillent (à partir de machines différentes) sur la même base de données, les problème de synchronisation pointent le bout du nez

Sans oublier un point capital : access est "windows only". On pourrait croire que ce n'est pas un problème, mais je n'en mettrais pas ma main au feu !

Tu pourras envisager une base autonome quand tu sera en déplacement et qui se synchronise avec la base principale au bureau : ce sera le point de difficulté.

Si tu pars sur access, le problème de synchronisation se posera même si les deux utilisateurs travaillent dans la même pièce!

Il sera beaucoup plus facile à résoudre -- que ce soit "dans les bureaux" ou en itinérant, si la base de données globale prend la forme d'un serveur, même si ce serveur n'est pas accessible par internet

Mais je dirais que tout dépend de la volumétrie.

Tout à fait

Mais vu la demande, je suppose qu'elle est faible.

Comme mon vénéré père dit toujours :

Il faut laisser croire les béguines, elles sont spécialistes et payées pour!

Autrement dit : méfie toi des a priori qui peuvent n'être valables que sur des très courtes périodes. Le simple fait que l'on parle dés le départ d'avoir trois utilisateurs plaide déjà en faveur d'une volumétrie que l'on pourrait ad minima qualifier de moyenne, même s'il n'y a qu'une seule entrée par personne et par jour, pour la simple et bonne raison que, à la fin de la journée, les trois utilisateurs devront travailler sur la base de donnée "en même temps" (ou, du moins, on doit partir du principe que ce sera le cas).

Or, cette situation se présentera, selon les propres termes de @VironFlo "à court termes", ce qui veut dire "assez rapidement", et ca risque encore de n'être qu'un début

Il serait dommage de se limiter volontairement en se basant sur une volumétrie faible et de devoir transférer l'ensemble des données déjà introduite sur un système "plus robuste" uniquement parce qu'on se rend compte qu'il devient impossible de travailler à quatre sur la base de données créées, et ce, même si on a -- au moins -- l'avantage d'avoir une structure "toute prête".

EDIT: D'autant plus que rien ne nous interdit (dés que l'on est en mesure de garantir l'accès à internet de la personne itinérante) d'envisager la création d'un "client léger" basé sur ou utilisant un navigateur internet pour y accéder.

Or, l'intégration d'une base de donnée access à un serveur ne peut (ne pouvait cela a peut-être changé ) se faire qu'ave ISS et, pour l'avoir fait à l'époque (il y a près de vingt ans de cela), je peux te garantir que ce n'est pas forcément le système de base de données le plus facile à intégrer