choix entre ACCESS et mySQL

Le
val
Bonjour,

Dans l'entreprise de production ou je travaille (15 personnes) nous
allons mettre en place une base de données de gestion des stocks. A
partir de chaque commande ou ordre de fabrication il faudra mettre à
jour les stocks de composants (quelques centaines de composants au
total). L'idée est de faciliter la gestion en mettant en place des
alertes quand le stock d'un composant passe sous un certain seuil. Ou
voir sous forme graphique l'historique des commandes d'un client, par
exemple. Ou tout autre chose : l'idéal est que ça puisse évoluer selon
nos besoins.

On va développer ça en interne. Se pose maintenant la question du
choix de l'outil. Mon patron penche pour ACCESS car ça lui semble
simple et efficace. Pour ma part j'ai une préférence pour PHP/mySQL
car je le connais et j'ai l'impression qu'avec PHP/mySQL et un peu de
JS on peut obtenir quelque chose de facile à utiliser, et surtout de
très souple. Il y a 7 ou 8 personnes qui utiliseront cette base de
données et il faudra donc la partager sur notre intranet (une dizaine
de PC équipé XP + un serveur W2k). Cela reste très "light" et il est
peu probable qu'il y ait plus de 2 ou 3 personnes connectées au même
moment.
J'aimerais avoir des avis extérieur quant au meilleur choix à faire.

Merci,

val
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal PONCET
Le #21862141
val a écrit :
J'aimerais avoir des avis extérieur quant au meilleur choix à faire.



Salut,

Le choix est évident : ça dépend des réponses aux bonnes questions !
;-)
Mais quelles sont les bonnes questions ?
Là aussi, ça dépend des besoins de l'organisation !

Un conseil, fait un tableau avec 5 colonnes : dans la première, les
besoins, dans la deuxième, les points faibles de MySql pour y répondre,
dans la troisième, ses points forts et, dans les deux dernières, la même
chose pour Access.
Ensuite tu pondère chaque réponse avec, par exemple, une notation du
type "-, --, ---" pour les points faibles et "+, ++, +++" pour les
points forts.
Tu fais le total des "-" et des "+" dans chaque colonne et tu as une
bonne idée de la tendance.
Si tu arrives dans des scores très proches, tu fais la balance avec des
généralités, du genre : culture de l'entreprise, goût personnel, etc...

Désolé, je ne crois pas aux réponses toutes faites.
Bonne chance,
Pascal
Mihamina (R12y) Rakotomandimby
Le #21862131
val -
Bonjour,



Bonjour,

l'idéal est que ça puisse évoluer selon
nos besoins. [...]
On va développer ça en interne. Se pose maintenant la question du
choix de l'outil. Mon patron penche pour ACCESS car ça lui semble
simple et efficace.



C'est lui qui va coder?

Pour ma part j'ai une préférence pour PHP/mySQL
car je le connais et j'ai l'impression qu'avec PHP/mySQL et un peu de
JS on peut obtenir quelque chose de facile à utiliser, et surtout de
très souple. Il y a 7 ou 8 personnes qui utiliseront cette base de
données et il faudra donc la partager sur notre intranet (une dizaine
de PC équipé XP + un serveur W2k). Cela reste très "light" et il est
peu probable qu'il y ait plus de 2 ou 3 personnes connectées au même
moment.
J'aimerais avoir des avis extérieur quant au meilleur choix à faire.



Moi j'opterai pour Python(+Zope)+MySQL
Le livre Zope [1] a un chapitre dédié à la mise en place d'un système proche
de ce que tu décris.

[1]: http://www.zopera.org/infos/zopebooks

Merci,

val
paul POULAIN
Le #21862121
val wrote:
J'aimerais avoir des avis extérieur quant au meilleur choix à faire.



moi je chercherai du coté de choses qui existent déjà, et sous licence
libre. A tout hasard, regarder du coté de dolibarr (et ne pas s'affoler de
voir une version ancienne mise en avant sur les sites, la 2.1 sort dans les
jours qui vient, mais les développeurs sont aussi nuls en communication que
bons en développement)
--
Paul, utilisateur de dolibarr
val
Le #21862101
On 25 avr, 14:23, Pascal PONCET wrote:
val a écrit :

> J'aimerais avoir des avis extérieur quant au meilleur choix à faire.

Salut,

Le choix est évident : ça dépend des réponses aux bonnes question s !
;-)
Mais quelles sont les bonnes questions ?
Là aussi, ça dépend des besoins de l'organisation !

Un conseil, fait un tableau avec 5 colonnes : dans la première, les
besoins, dans la deuxième, les points faibles de MySql pour y répondr e,
dans la troisième, ses points forts et, dans les deux dernières, la m ême
chose pour Access.
Ensuite tu pondère chaque réponse avec, par exemple, une notation du
type "-, --, ---" pour les points faibles et "+, ++, +++" pour les
points forts.
Tu fais le total des "-" et des "+" dans chaque colonne et tu as une
bonne idée de la tendance.
Si tu arrives dans des scores très proches, tu fais la balance avec des
généralités, du genre : culture de l'entreprise, goût personnel, etc...

Désolé, je ne crois pas aux réponses toutes faites.
Bonne chance,
Pascal



Merci pour le conseil. J'avais fait le tableau mais j'avais pas eu
l'idée de quantifier avec des + et des -.

val
val
Le #21862091
On 25 avr, 15:17, "Mihamina (R12y) Rakotomandimby"
polyvalente.fr> wrote:

C'est lui qui va coder?




Ben non, c'est bibi qui va coder. D'ailleurs c'est un peu ça le
problème car je veux bien jouer le match du mieux que je peux mais ça
m'embête beaucoup qu'on m'impose le choix de la raquette.

Moi j'opterai pour Python(+Zope)+MySQL
Le livre Zope [1] a un chapitre dédié à la mise en place d'un syst ème proche
de ce que tu décris.

[1]:http://www.zopera.org/infos/zopebooks




Ah, super ! Je l'achèterais ce week-end. Même si on se tourne vers une
autre solution ça me donnera certainement des idées.

val
michel martins
Le #21862081
Access comporte des inconvénients importants :
Encombrement du réseau
Limitation pratique du nombre d'utilisateurs simultanés (max : 10)
Limitation d'une base à 2 Go
SGBD lié à Windows
Jean-Marc Molina
Le #21862071
val wrote:
Dans l'entreprise de production ou je travaille (15 personnes) nous
allons mettre en place une base de données de gestion des stocks. A
partir de chaque commande ou ordre de fabrication il faudra mettre à
jour les stocks de composants (quelques centaines de composants au
total). L'idée est de faciliter la gestion en mettant en place des
alertes quand le stock d'un composant passe sous un certain seuil. Ou
voir sous forme graphique l'historique des commandes d'un client, par
exemple. Ou tout autre chose : l'idéal est que ça puisse évoluer selon
nos besoins.

On va développer ça en interne. Se pose maintenant la question du
choix de l'outil.



Compte tenu que vous êtes une petite structure, il faudrait aussi peser le
pour et le contre concernant le développement en interne :
* Est-ce que ça vaut la peine de monopoliser une personne ?
* Avez-vous pensé au coût astronomique d'un développement en interne comparé
à l'utilisation d'une solution clé-en-main (Utilisation d'un logiciel libre,
achat d'une licence...) ?
* Avez-vous pensé à la nécessité de maintenir l'application développée
(Ajout de fonctionnalités, correction des "bugs"...) ?
* Est-ce que le développement d'une telle application rentre dans vos
compétences et les objectifs de l'entreprise ?
* Votre patron ne serait-il pas très lésé si la personne chargée du
développement venait à quitter l'entreprise ?
* Je ne parle même pas des nombreux cas où aucune documentation n'avait été
rédigée par le ou les développeurs : pas de guide du développeur, code
source non documenté, pas de manuel utilisateur...

Beaucoup d'entreprises jetent l'argent par les fenêtres et ignorent
complètement les contraintes du développement en interne. Les patrons n'ont
souvent que trop peu de connaissances dans le domaine et les développeurs
pensent plus à se faire plaisir qu'à servir les intérêts de l'entreprise. Ne
pas prendre en compte l'alternative externe c'est vraiment tirer du plomb
dans l'aile de son entreprise, le pire c'est que certains développeurs le
savent mais ne disent rien à leur patron.

Une solution peut être plus viable serait d'opter pour un logiciel libre et
de l'adapter à vos besoins ou de faire appel à un prestataire externe si
besoin. Tout le monde est satisfait :
* On répond au besoin de l'entreprise rapidement et efficacement.
* Le coût du patron n'est pas pendu :)
* Le développeur se fait raisonnablement plaisir.
Jean-Marc Molina
Le #21862061
val wrote:
Se pose maintenant la question du
choix de l'outil. Mon patron penche pour ACCESS car ça lui semble
simple et efficace. Pour ma part j'ai une préférence pour PHP/mySQL
car je le connais et j'ai l'impression qu'avec PHP/mySQL et un peu de
JS on peut obtenir quelque chose de facile à utiliser, et surtout de
très souple. Il y a 7 ou 8 personnes qui utiliseront cette base de
données et il faudra donc la partager sur notre intranet (une dizaine
de PC équipé XP + un serveur W2k). Cela reste très "light" et il est
peu probable qu'il y ait plus de 2 ou 3 personnes connectées au même
moment.



Avantages d'Access :
* Simplicité d'accès du développement.
* Environnement intégré pour dessiner les formulaires, modéliser la base de
données, définir le comportement des objets...
* Convient pour développer rapidement de petites applications.

Défauts d'Access :
* Windows
* Limitations du SGBD (Jet)
* Base locale à partager sur un réseau
* Coûts des licences MS Office Pro
* Installation de MS Office sur tous les postes clients

Avantages d'une solution en PHP/MySQL :
* Prototypage très rapide (mais c'est à double-tranchant) d'une application.
On peut rapidement proposer une alpha-application aux utilisateurs, avoir du
retour et voir si les fonctionnalités proposées répondent aux besoins
exprimés.
* Multi-plate-formes (Linux, Windows...)
* SGBD accessible et puissant
* Logiciel libre
* Nombreux prestataires pour aider au développement (Maintenance,
"refactoring"...)
* Possibilité d'utiliser les standards du Web et formats ouverts :
XHTML/CSS, génération de rapports au format Open Document/PDF, exportation
au format XML...
* Technologies libres et nombreux outils de développement pour atteindre une
facilité d'utilisation aussi bonne que celle d'Access : Eclipse, débogueur
JavaScript/PHP, modélisation UML, validateurs XHTML/CSS, "frameworks"
(PEAR...)...
* Application Web, pas de déploiement sur les postes clients, on a juste
besoin d'un navigateur (Firefox) pour l'utiliser.

J'insiste sur ce dernier argument car on se retrouve parfois chez un client
à vouloir mettre à jour son stock ou à le vérifier ! Access reste très fermé
pour ce genre de pratiques nomades.

Défauts d'une solution en PHP/MySQL :
* Délai de développement pour une équipe non expérimentée. Et on peut faire
un véritable carnage en un temps record. Vite fait, mal fait.

Bon je ne suis sans doute pas objectif car j'ai connu Access et ma rencontre
avec les technologies libres (PHP, MySQL...) a été comme une révoéluation
(?!). Je ne vois vraiment plus d'inconvénients à développer en PHP/MySQL.
Certes au début on a l'impression de réinventer la roue car on est un peu
perdu dans cette jungle de technologies mais après plusieurs années on s'y
retrouve. Après honnêtement je pense que développer en interne quand on s'y
connait pas assez... C'est suicidaire pour l'entreprise et complètement
irresponsable. Mais que cela ne t'empêche pas de bidouiller le gestionnaire
des stocks chez toi afin d'acquérir des connaissances en la matière, vous
pourrez toujours l'adopter plus tard si vous optez dès aujourd'hui pour une
solution clé-en-main libre reposant sur des formats ouverts, question de ne
pas vous retrouvez prisionnier d'un logiciel propriétaire (et de son
développeur/éditeur) gérant les stocks dans une base fermée (ça devient pire
quand elle est pas documentée et qu'aucune API ne permet d'accéder aux
données). C'est le "troll" du jour*.

* : Oops je suis plus sur news://fr.comp.applications.libres :P
Pif
Le #21862041
Bonjour, sans vouloir rentrer dans les réponses toutes faites...

Pour une petite entreprise et un petit projet, perso, c'est sur que
Access offre des avantages : outre la base, l'utilisateur peut faire
très facilement des rapports, états, formulaires, etc.

Mais bon, Access ca restre très (trop) fermé pour moi...

Pour faire du développement rapide et simple, y'a un ptit outil sympa si
on veut pas rentrer dans du génie logiciel pur et dur :

http://www.framasoft.net/article3413.html
http://www.sashipamelba.com/fr/

tu as aussi des solutions de tout pret en open source probablement....
exemple : http://custom.sourceforge.net/

essaye sur freshmeat par exemple...

Pour la question du PHP, y'a pas photo, c'est du scripting, pas de la
programmation ou du génie logiciel : je sais, ca peut paraitre sectaire,
mais je préfère faire du MySQL...

Tu as aussi des outils du type WinDev en intermédiaire... mais bon,
c'est du proprio, cher, mieux qu'access, qui mérite pas forcément
l'investissement pour un usage unique...
V. Le Page
Le #21862031
JM Molina a écrit :
Compte tenu que vous êtes une petite structure, il faudrait aussi peser le
pour et le contre concernant le développement en interne :
* Est-ce que ça vaut la peine de monopoliser une personne ?
* Avez-vous pensé au coût astronomique d'un développement en interne comparé
à l'utilisation d'une solution clé-en-main (Utilisation d'un logiciel libre,
achat d'une licence...) ?



Oui, et j'avais d'ailleurs proposé à mon patron de rechercher plutôt
une solution 'clés en main' mais il préfère le sur mesure. C'est comme
ça.

* Avez-vous pensé à la nécessité de maintenir l'application développée
(Ajout de fonctionnalités, correction des "bugs"...) ?



Oui et j'espère que l'on pourra la faire évoluer. C'est pour ça que je
propose PHP/mySQL car je pense que ça peut être très souple.
Actuellement on utilise comme base de données un logiciel appelé QR
(vient de QA = Question & Answer de Symantec) et il fait bien son
boulot de gestion des commandes, ordres de fabrication et bons de
livraison mais il date un peu (1992?) et on risque d'avoir des
problèmes à le faire évoluer.

* Est-ce que le développement d'une telle application rentre dans vos
compétences et les objectifs de l'entreprise ?



Je ne suis pas informaticien de formation mais je pense être capable de
le faire. L'année dernière j'avais codé le reporting des commandes et
livraisons vers notre maison mère avec PHP/mySQL et ça c'était bien
passé. Quant aux objectifs de l'entreprise, pour répondre à votre
question, on est pil poil dedans car en ce moment le business marche
bien et la production est débordée. Du coup soulager la production
d'une partie de la gestion des stocks est devenu une priorité.
D'ailleurs la demande vient de là.

* Votre patron ne serait-il pas très lésé si la personne chargée du
développement venait à quitter l'entreprise ?



Certainement si (et j'ai crédité ça d'un -- dans la colonne des pours
et des contres :-). Mais je crois qu'un code bien documenté peut
survivre.

* Je ne parle même pas des nombreux cas où aucune documentation n'avait été
rédigée par le ou les développeurs : pas de guide du développeur, code
source non documenté, pas de manuel utilisateur...

Beaucoup d'entreprises jetent l'argent par les fenêtres et ignorent
complètement les contraintes du développement en interne. Les patrons n'ont
souvent que trop peu de connaissances dans le domaine et les développeurs
pensent plus à se faire plaisir qu'à servir les intérêts de l'entreprise. Ne
pas prendre en compte l'alternative externe c'est vraiment tirer du plomb
dans l'aile de son entreprise, le pire c'est que certains développeurs le
savent mais ne disent rien à leur patron.



D'accord avec vous. Mais bon il faut voir que c'est quand même une
petite appli. On ne cherche pas l'usine à gaz. Il s'agit seulement de
faire une base de données et de déclencher sa mise à jour au fur et à
mesure de l'entrée des commandes. Je pense que un mois de travail à
temps plein devrait suffire, soit disons 6 mois 1 an avant d'avoir un
truc fonctionnel car ce genre d'activité reste marginale et on est
souvent pris par d'autres choses dans la journée :-) Je pense que l'on
pourrait même faire ça avec QR mais il est temps de passer à une base
de données consultables par d'autres applis. Le pb de QR c'est que tout
doit passer par lui et ses fonctionnalités pour accéder et traîter les
données. Ca finit par limiter sérieusement.

Une solution peut être plus viable serait d'opter pour un logiciel libre et
de l'adapter à vos besoins ou de faire appel à un prestataire externe si
besoin. Tout le monde est satisfait :
* On répond au besoin de l'entreprise rapidement et efficacement.
* Le coût du patron n'est pas pendu :)
* Le développeur se fait raisonnablement plaisir.



Adapter un logiciel libre est séduisant mais je ne me crois pas capable
de reprendre du code écrit par un autre. Ca me prendrait trop de temps.
Un prestataire, pourquoi pas ? Mais j'ai un peu peur que l'addition
soit salée...

Merci pour votre email plein de conseils.

val
Publicité
Poster une réponse
Anonyme