Discussion :

[sangoke]

Bonjour à tous,

je suis actuellement en stage dans une entreprise qui a pour activité le transport de personnes en car.

La gestion des amendes émises par les contrôleurs est obsolète, elle ne permet que très peu de recherche et aucune statistiques n'est effectuée. Ma mission est donc de développer une nouvelle application permettant de les gérer et de pouvoir faire des recherches par différents critères sur les PV, quelques statistiques etc...

Ma question est la suivante, vaut-il mieux que j'utilise Excel, Access,une combinaison des deux ou même un autre SGBD ? sachant qu'il n'y aura qu'un seul utilisateur sur ma base de données et que je suis totalement libre pour proposer une nouvelle solution.

A la base je comptais utiliser uniquement Excel mais vu que j'ai une base de données relationnelle (enfin je l'ai faite comme ça, une autre méthode est peut-être possible), Access me semble plus approprié mais du coup c'est pour les éventuels graphiques ou "rapports" que je me pose des questions.

Merci d'avance pour vos éclaircissements et vos idées.

[DotNetMatt]

Ma question est la suivante, vaut-il mieux que j'utilise Excel, Access,une combinaison des deux ou même un autre SGBD ? sachant qu'il n'y aura qu'un seul utilisateur sur ma base de données et que je suis totalement libre pour proposer une nouvelle solution.

Surtout pas Access ! Ni Excel ! Access est bien pour faire des petites applis dans son coin, en mode quick and dirty, genre un comptable qui va avoir besoin d'une petite moulinette pour faire deux/trois calculs de temps en temps, mais qui ne peut pas avoir le budget pour disposer d'une vraie application.

Quant à Excel, sa fonction est d'être un tableur. Même s'il est très puissant, ça ne doit pas servir de base de données pour un projet, sauf si tu es dans le même cas que le comptable ci-dessus.

Donc tu as vu juste, il vaut mieux cibler un autre SGBD. Tu as par exemple SQL Server 2012 Express Edition, qui est totalement gratuit.

En ce qui concerne les rapports, tu as des outils très puissants fournis avec la suite SQL Server, dont Reporting Services :
--- Reporting Services (SSRS)
--- What's New (Reporting Services)
--- Microsoft SQL Server 2012 training : Reporting Services

Pour des scénarios plus poussés, mais qui nécessitent pas mal de travail de développement, tu peux regarder du côté de Component Art, qui propose une série de composants graphiques destinés à réaliser des dashboards interactifs et multi-plateforme (PC / Web / mobile). Ca, c'est pas mal mais ça demande plus de travail que SSRS, notamment parce qu'il faut connaître le C# pour pouvoir créer les sources de données.

[sangoke]

Merci pour ta réponse, mais il s'agit d'une application dont une seule personne se servira et pas tous les jours, pour enregistrer les PV qui ont été émis, faire des relances au client s'il n'a pas payé son amende, générer un récapitulatif des amendes avec quelques statistiques (taux de recouvrement des amendes, graphique d'évolution du nombre d'amendes, etc..) et des feuilles de caisses pour la compta.

Ce qui rejoins un peut l'exemple du comptable au final il me semble non ?

[DotNetMatt]

Oui effectivement ça rejoint l'exemple du comptable. Mais d'une manière générale, ça ne justifie pas pour autant l'utilisation d'Access ou d'Excel. Tu es en entreprise, tu n'es pas dans ton coin en train de bidouiller pour le fun en mode quick and dirty.

In fine, c'est à clarifier avec ton responsable. Qu'attend-il vraiment ? Une application évolutive ? Un truc fait rapidement dans un coin, sans tenir compte du futur ?

[EDIT] Aussi je pense que quitte à être en stage, et surtout si tu as le champ libre pour proposer des solutions, tu as tout à y gagner à mettre en oeuvre une solution pro, basée sur SQL Server + Reporting Services, et là je parle de ton CV

Pense à l'après stage. Sur le CV ce sera clairement plus valorisant d'avoir une expérience sur ces technos, plutôt que sur Access. Et tu auras aussi rendu service à l'entreprise en lui mettant en place une solution robuste, durable et qu'elle pourra potentiellement faire évoluer plus tard sans avoir à tout refaire.

[sangoke]

Oui oui c'est sur ça ne justifie pas l'usage d'Excel ou Access mais je connais bien cela c'est pour ça que je me dirigeais plus vers cette solution. Je ne me suis jamais servis de SQL Server...

D'autant plus qu'a l'heure actuelle la gestion des amendes est effectuée par un seul PC connecté à un vax (je ne sais pas si tu connais ça date de la préhistoire ^^) avec un logiciel sur lequel on ne peut à peu près rien faire et ils veulent s'en séparer donc rien qu'une application Excel ou Access serait une révolution lol.

En effet je vais clarifier cela avec mon responsable mais c'est sûr que ce serait plus pro avec ta solution et plus valorisant pour mon CV car Excel et Access c'est vraiment la base.

[DotNetMatt]

Oui oui c'est sur ça ne justifie pas l'usage d'Excel ou Access mais je connais bien cela c'est pour ça que je me dirigeais plus vers cette solution. Je ne me suis jamais servis de SQL Server...

Si tu connais Access, tu n'auras pas trop de mal à te faire à SQL Server. Le dénominateur commun c'est le langage SQL. Après tout ce qui est configuration, tu trouveras plein d'articles sur le net si tu as des besoins particuliers.

Le plus important, mais ça c'est vrai que ce soit pour du Access ou pour tout autre SGBD, c'est la modélisation. Si la modélisation n'est pas bonne, le projet ne sera pas bon, car tôt ou tard, des problèmes de performance surgiront. Il faut donc bien essayer de modéliser au moins en 3NF.

D'autant plus qu'a l'heure actuelle la gestion des amendes est effectuée par un seul PC connecté à un vax (je ne sais pas si tu connais ça date de la préhistoire ^^) avec un logiciel sur lequel on ne peut à peu près rien faire et ils veulent s'en séparer donc rien qu'une application Excel ou Access serait une révolution lol.

En effet je vais clarifier cela avec mon responsable mais c'est sûr que ce serait plus pro avec ta solution et plus valorisant pour mon CV car Excel et Access c'est vraiment la base.

Effectivement si Excel/Access est une révolution, alors imagine ce que ce sera avec SQL Server

Encore une fois, et j'insiste, l'idée, ce n'est pas d'utiliser du SQL Server pour utiliser du SQL Server. C'est plus de mettre en place une solution pérenne et robuste. Aujourd'hui, une seule personne se sert de l'appli. OK, mais qu'en sera-t-il demain ? C'est pareil pour tout, il faut penser à aujourd'hui mais aussi à demain et à après-demain.

Lorsque je discute avec des collègues ayant plus d'ancienneté que moi dans le métier, il y en a pas mal qui ressortent des anecdotes du genre un mec a fait un truc dans son coin (le comptable), puis il l'a montré à un de ses collègues, qui a aussi décidé de l'utiliser en ajoutant quelques fonctionnalités, parce que ça lui faisait gagner du temps. Au final, 10 personnes l'utilisent. Le projet prend de l'ampleur, mais il n'est pas géré par des pros, donc pas d'archi, pas de doc, pas de specs...

In fine, un beau jour un directeur lève son derrière de sa chaise, et vient dire à l'IT "bon les gars, il faut nous passer ça en appli digne de ce nom parce que là c'est trop lent et pas assez efficace pour travailler à plusieurs, sans perte de données et en gardant les mêmes règles de calcul. Mr Dupond répondra à vos questions".

Et là c'est le début des festivités pour comprendre ce qui a été fait etc...

[sangoke]

Merci pour tous ces conseils et précisions et anecdotes , je pense donc que je vais partir la-dessus.