J'aimerais avoir des avis extérieur quant au meilleur choix à faire.
J'aimerais avoir des avis extérieur quant au meilleur choix à faire.
J'aimerais avoir des avis extérieur quant au meilleur choix à faire.
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.
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
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.
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
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.
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
J'aimerais avoir des avis extérieur quant au meilleur choix à faire.
J'aimerais avoir des avis extérieur quant au meilleur choix à faire.
J'aimerais avoir des avis extérieur quant au meilleur choix à faire.
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
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
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
C'est lui qui va coder?
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
C'est lui qui va coder?
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
C'est lui qui va coder?
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
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.
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.
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.
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.
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.
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.
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...) ?
* 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.
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...) ?
* 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.
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...) ?
* 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.