Recherche bons samaritains pour conseils de programmation
20 réponses
Eklektik
Je replace le contexte : je suis programmeur de formation, mais j'ai mal
tournée, été bossé dans autre chose, maman m'en veut bien sur, bref, au
boulot, sachant que j'aietudié la dedans, ils me demandent de leur «
bidouiller » quelque chose :
Un programme gérant un inventaire, avec des rapports, des transactions,
différents processus(comme celui de la production) qui influent sur cet
inventaire...etc
Positif pour moi, pour marquer quelques point, bien évidemment, et surtout
revenir a la programmation qui me manque.
Mais..je manque d'expérience, bien qu'étant loin d'avoir été une brele en
programmation dans le temps..
Ce programme doit gérer une base de données, des produits avec leurs codes,
des espaces de stockage..ce n'est pas une quantité monstrueuse de donneés on
s'en doute, c'est pour une pme, avec peut etre 4000 produits a gerer au
grand maximum.
De prime abord, je me serais mis a penser à une base de données access ou
autre, pilotée par VB, ou VC++...mais tout doit être en réseau, plusieurs
postes accèdant simultanément..d'ou une partie client et une autre serveur a
concevoir dans ce genre de cas...
Un ami me conseille : pourquoi ne le fais tu pas en ASP, avec une base de
données Acces(Windows oblige)? Interface HTML, un intranet, un site
interne..
Comme je dois savoir dans quelle direction, je vais m'en aller, pour acheter
les bouquins, et commencer a potasser, essayer, j'aimerais avoir d'autres
avis..ASP+Access, est ce viable et pratique? D'autres suggestions?
> Surtout que le volume n'est pas important, et ne risque pas de le devenir....
Alors ça va, surtout si tu n'as pas trop d'appels concurrents.
Pour l'interface web, non il n'y a rien d'imposé. Admettons qu'il ce soit fait en VB, piloter une base de données Access,
pour
le differents postes qui y accedent, faut il, d'une maniere ou d'ue autre, au point de vue programmation, gerer un aspect "reseau"? Si oui, lequel? ou se situe la complexité?
Niveau réseau ? Y'a rien. déclarer un driver odbc au pire. Rien de méchant.
> En fait à ta place je choisirais en fonction du langage où te te sens le > plus à l'aise... Assembleur, et C++....sous Dos, unix/linux, et une version de TI sous Windows....voila sous quoi j'etais le plus a l'aise, ou du moins que j'affectionnais le plus....
J'avais fait du VB, et je n'aimais pas le basic...
On m'a egalement parlé de Windev.....bien?
WinDev c'est pas mal. Mais si tu connais déjà C++, tu vas gagner un peu de temps. Essayes C++ Builder de borland. Pour l'accès aux BDD tu seras pas déçu.
> Surtout que le volume n'est pas important, et ne risque pas de le
devenir....
Alors ça va, surtout si tu n'as pas trop d'appels concurrents.
Pour l'interface web, non il n'y a rien d'imposé.
Admettons qu'il ce soit fait en VB, piloter une base de données Access,
pour
le differents postes qui y accedent, faut il, d'une maniere ou d'ue autre,
au point de vue programmation, gerer un aspect "reseau"?
Si oui, lequel? ou se situe la complexité?
Niveau réseau ? Y'a rien. déclarer un driver odbc au pire. Rien de méchant.
> En fait à ta place je choisirais en fonction du langage où te te sens le
> plus à l'aise...
Assembleur, et C++....sous Dos, unix/linux, et une version de TI sous
Windows....voila sous quoi j'etais le plus a l'aise, ou du moins que
j'affectionnais le plus....
J'avais fait du VB, et je n'aimais pas le basic...
On m'a egalement parlé de Windev.....bien?
WinDev c'est pas mal. Mais si tu connais déjà C++, tu vas gagner un peu de
temps. Essayes C++ Builder de borland. Pour l'accès aux BDD tu seras pas
déçu.
> Surtout que le volume n'est pas important, et ne risque pas de le devenir....
Alors ça va, surtout si tu n'as pas trop d'appels concurrents.
Pour l'interface web, non il n'y a rien d'imposé. Admettons qu'il ce soit fait en VB, piloter une base de données Access,
pour
le differents postes qui y accedent, faut il, d'une maniere ou d'ue autre, au point de vue programmation, gerer un aspect "reseau"? Si oui, lequel? ou se situe la complexité?
Niveau réseau ? Y'a rien. déclarer un driver odbc au pire. Rien de méchant.
> En fait à ta place je choisirais en fonction du langage où te te sens le > plus à l'aise... Assembleur, et C++....sous Dos, unix/linux, et une version de TI sous Windows....voila sous quoi j'etais le plus a l'aise, ou du moins que j'affectionnais le plus....
J'avais fait du VB, et je n'aimais pas le basic...
On m'a egalement parlé de Windev.....bien?
WinDev c'est pas mal. Mais si tu connais déjà C++, tu vas gagner un peu de temps. Essayes C++ Builder de borland. Pour l'accès aux BDD tu seras pas déçu.
Alexandre
> sur la lecture de ton énoncé, ma première idée serait mysql, qui me semble adapté a tout ce qu'il faut, et plus "mieux bien" que access.
FAUX : MySQL n'est pas un SGBD. Pas mieux en tout cas qu'access. Voire pire. Pour le posteur à mon avis la problèmatique est simple : - peu de réseau, peu d'appels simultanés, etc... -> base access ou paradox. Simple. Voire très simple à faire. - un peu + de réseau et/ou plus de monde en même temps, droits différents, etc... -> PostGreSQL.
MySQL c'est, à mon gout, un outil pour faire des sites web qui traitent des données. Pas pour une "vraie" bdd relationnelle.
>
sur la lecture de ton énoncé, ma première idée serait mysql, qui me semble
adapté a tout ce qu'il faut, et plus "mieux bien" que access.
FAUX : MySQL n'est pas un SGBD. Pas mieux en tout cas qu'access. Voire pire.
Pour le posteur à mon avis la problèmatique est simple :
- peu de réseau, peu d'appels simultanés, etc... -> base access ou
paradox. Simple. Voire très simple à faire.
- un peu + de réseau et/ou plus de monde en même temps, droits
différents, etc... -> PostGreSQL.
MySQL c'est, à mon gout, un outil pour faire des sites web qui traitent des
données.
Pas pour une "vraie" bdd relationnelle.
> sur la lecture de ton énoncé, ma première idée serait mysql, qui me semble adapté a tout ce qu'il faut, et plus "mieux bien" que access.
FAUX : MySQL n'est pas un SGBD. Pas mieux en tout cas qu'access. Voire pire. Pour le posteur à mon avis la problèmatique est simple : - peu de réseau, peu d'appels simultanés, etc... -> base access ou paradox. Simple. Voire très simple à faire. - un peu + de réseau et/ou plus de monde en même temps, droits différents, etc... -> PostGreSQL.
MySQL c'est, à mon gout, un outil pour faire des sites web qui traitent des données. Pas pour une "vraie" bdd relationnelle.
Alexandre
"Arnaud Debaene" a écrit dans le message de news:3f8f8921$0$13285$
rufus larondelle wrote: > Salut, > > sur la lecture de ton énoncé, ma première idée serait mysql, qui me > semble adapté a tout ce qu'il faut, et plus "mieux bien" que access.
Pas d'accord : D'après la description de la problématique de l'OP, il n' y aura pas de gros besoins en performances (le point fort de MySQL par
rapport
aux autres bases). Par contre la structure de la base rique d'être relativement complexe, et
là
l'abscence de jointures, de contrôle d'intégrité référentielle, de tiggers et de procédures stockées - bref tout ce qui manque à MySQL pour être un "vrai" SGBD - risque d'être problématique.
Bon c'est vrai qu'y a pas non plus tout ça dans access.
Y'a pas de jointures dans MySQL ? C'est encore plus une merde que je ne pensais !!!!!
"Arnaud Debaene" <adebaene@club-internet.fr> a écrit dans le message de
news:3f8f8921$0$13285$626a54ce@news.free.fr...
rufus larondelle wrote:
> Salut,
>
> sur la lecture de ton énoncé, ma première idée serait mysql, qui me
> semble adapté a tout ce qu'il faut, et plus "mieux bien" que access.
Pas d'accord : D'après la description de la problématique de l'OP, il n' y
aura pas de gros besoins en performances (le point fort de MySQL par
rapport
aux autres bases).
Par contre la structure de la base rique d'être relativement complexe, et
là
l'abscence de jointures, de contrôle d'intégrité référentielle, de tiggers
et de procédures stockées - bref tout ce qui manque à MySQL pour être un
"vrai" SGBD - risque d'être problématique.
Bon c'est vrai qu'y a pas non plus tout ça dans access.
Y'a pas de jointures dans MySQL ? C'est encore plus une merde que je ne
pensais !!!!!
"Arnaud Debaene" a écrit dans le message de news:3f8f8921$0$13285$
rufus larondelle wrote: > Salut, > > sur la lecture de ton énoncé, ma première idée serait mysql, qui me > semble adapté a tout ce qu'il faut, et plus "mieux bien" que access.
Pas d'accord : D'après la description de la problématique de l'OP, il n' y aura pas de gros besoins en performances (le point fort de MySQL par
rapport
aux autres bases). Par contre la structure de la base rique d'être relativement complexe, et
là
l'abscence de jointures, de contrôle d'intégrité référentielle, de tiggers et de procédures stockées - bref tout ce qui manque à MySQL pour être un "vrai" SGBD - risque d'être problématique.
Bon c'est vrai qu'y a pas non plus tout ça dans access.
Y'a pas de jointures dans MySQL ? C'est encore plus une merde que je ne pensais !!!!!
Alexandre
> de l'Access tout cours. moins on en écrit, moins on écrit de trucs
foireux.
pas sur, ça...
le formalisme d'Access est simple et bien Adapté. je doute que vous ayez
un
tel confort avec du C++.
Les possibilités ne sont quand même pas les mêmes !!!!
pour les Reports, ceux d'Access sont pas mal, mais Crystal Reports est à
mon
gout top confort.
C'est vrai ça.
> de l'Access tout cours. moins on en écrit, moins on écrit de trucs
foireux.
pas sur, ça...
le formalisme d'Access est simple et bien Adapté. je doute que vous ayez
un
tel confort avec du C++.
Les possibilités ne sont quand même pas les mêmes !!!!
pour les Reports, ceux d'Access sont pas mal, mais Crystal Reports est à
> de l'Access tout cours. moins on en écrit, moins on écrit de trucs
foireux.
pas sur, ça...
le formalisme d'Access est simple et bien Adapté. je doute que vous ayez
un
tel confort avec du C++.
Les possibilités ne sont quand même pas les mêmes !!!!
pour les Reports, ceux d'Access sont pas mal, mais Crystal Reports est à
mon
gout top confort.
C'est vrai ça.
Arnaud Debaene
Alexandre wrote:
"Arnaud Debaene" a écrit dans le message de news:3f8f8921$0$13285$
rufus larondelle wrote:
Salut,
sur la lecture de ton énoncé, ma première idée serait mysql, qui me semble adapté a tout ce qu'il faut, et plus "mieux bien" que access.
Pas d'accord : D'après la description de la problématique de l'OP, il n' y aura pas de gros besoins en performances (le point fort de MySQL par rapport aux autres bases). Par contre la structure de la base rique d'être relativement complexe, et là l'abscence de jointures, de contrôle d'intégrité référentielle, de tiggers et de procédures stockées - bref tout ce qui manque à MySQL pour être un "vrai" SGBD - risque d'être problématique.
Bon c'est vrai qu'y a pas non plus tout ça dans access.
Access fait le controle d'intégrité référentielle.
Y'a pas de jointures dans MySQL ? C'est encore plus une merde que je ne pensais !!!!!
Oui et non : tu peux déclarer des jointures dans tes requêtes SQL, par contre il n'y a pas de jointures permanentes entre tables, donc aps de possibilité de faire du contrôle d'intégrité référentielle.
Arnaud
Alexandre wrote:
"Arnaud Debaene" <adebaene@club-internet.fr> a écrit dans le message
de news:3f8f8921$0$13285$626a54ce@news.free.fr...
rufus larondelle wrote:
Salut,
sur la lecture de ton énoncé, ma première idée serait mysql, qui me
semble adapté a tout ce qu'il faut, et plus "mieux bien" que access.
Pas d'accord : D'après la description de la problématique de l'OP,
il n' y aura pas de gros besoins en performances (le point fort de
MySQL par rapport aux autres bases).
Par contre la structure de la base rique d'être relativement
complexe, et là l'abscence de jointures, de contrôle d'intégrité
référentielle, de tiggers et de procédures stockées - bref tout ce
qui manque à MySQL pour être un "vrai" SGBD - risque d'être
problématique.
Bon c'est vrai qu'y a pas non plus tout ça dans access.
Access fait le controle d'intégrité référentielle.
Y'a pas de jointures dans MySQL ? C'est encore plus une merde que je
ne pensais !!!!!
Oui et non : tu peux déclarer des jointures dans tes requêtes SQL, par
contre il n'y a pas de jointures permanentes entre tables, donc aps de
possibilité de faire du contrôle d'intégrité référentielle.
"Arnaud Debaene" a écrit dans le message de news:3f8f8921$0$13285$
rufus larondelle wrote:
Salut,
sur la lecture de ton énoncé, ma première idée serait mysql, qui me semble adapté a tout ce qu'il faut, et plus "mieux bien" que access.
Pas d'accord : D'après la description de la problématique de l'OP, il n' y aura pas de gros besoins en performances (le point fort de MySQL par rapport aux autres bases). Par contre la structure de la base rique d'être relativement complexe, et là l'abscence de jointures, de contrôle d'intégrité référentielle, de tiggers et de procédures stockées - bref tout ce qui manque à MySQL pour être un "vrai" SGBD - risque d'être problématique.
Bon c'est vrai qu'y a pas non plus tout ça dans access.
Access fait le controle d'intégrité référentielle.
Y'a pas de jointures dans MySQL ? C'est encore plus une merde que je ne pensais !!!!!
Oui et non : tu peux déclarer des jointures dans tes requêtes SQL, par contre il n'y a pas de jointures permanentes entre tables, donc aps de possibilité de faire du contrôle d'intégrité référentielle.
Arnaud
Alexandre
> > > Bon c'est vrai qu'y a pas non plus tout ça dans access.
Access fait le controle d'intégrité référentielle.
Oui, je savais. J'ai dit "tout ça". Ceci, je ne connais pas assez access, peut-être qu'il fait même tout ce qu'on est en droit d'attendre d'un SGBD... Mais je ne crois pas avoir vu de gestion des droits par exemple.
> Y'a pas de jointures dans MySQL ? C'est encore plus une merde que je > ne pensais !!!!! Oui et non : tu peux déclarer des jointures dans tes requêtes SQL, par contre il n'y a pas de jointures permanentes entre tables, donc aps de possibilité de faire du contrôle d'intégrité référentielle.
Oui, donc pas de jointures. Heuresement encore qu'on puisse en faire dans les requetes, sinon autant utiliser un tableau.
> >
> Bon c'est vrai qu'y a pas non plus tout ça dans access.
Access fait le controle d'intégrité référentielle.
Oui, je savais. J'ai dit "tout ça". Ceci, je ne connais pas assez access,
peut-être qu'il fait même tout ce qu'on est en droit d'attendre d'un SGBD...
Mais je ne crois pas avoir vu de gestion des droits par exemple.
> Y'a pas de jointures dans MySQL ? C'est encore plus une merde que je
> ne pensais !!!!!
Oui et non : tu peux déclarer des jointures dans tes requêtes SQL, par
contre il n'y a pas de jointures permanentes entre tables, donc aps de
possibilité de faire du contrôle d'intégrité référentielle.
Oui, donc pas de jointures. Heuresement encore qu'on puisse en faire dans
les requetes, sinon autant utiliser un tableau.
> > > Bon c'est vrai qu'y a pas non plus tout ça dans access.
Access fait le controle d'intégrité référentielle.
Oui, je savais. J'ai dit "tout ça". Ceci, je ne connais pas assez access, peut-être qu'il fait même tout ce qu'on est en droit d'attendre d'un SGBD... Mais je ne crois pas avoir vu de gestion des droits par exemple.
> Y'a pas de jointures dans MySQL ? C'est encore plus une merde que je > ne pensais !!!!! Oui et non : tu peux déclarer des jointures dans tes requêtes SQL, par contre il n'y a pas de jointures permanentes entre tables, donc aps de possibilité de faire du contrôle d'intégrité référentielle.
Oui, donc pas de jointures. Heuresement encore qu'on puisse en faire dans les requetes, sinon autant utiliser un tableau.
SaadE
> Pourquoi "Access (Windows oblige)" ??? Il existe d'autres moteurs de bases de données! Selon le budget et les besoins exacts, je verrais bien Access, Postgres ou SQL Serveur dans ton cas (Access rique d'être limite si tu a plus de ~ 10 connections simultanées).
Windows oblige, car il est imposé! Aprés...Access...car pourquoi pas! :-) Et aucune chance d'avoir plus de dix connexions simultanées
Enfin le plus important, si tu choisis l'option ASP.NET, tu va être obligé de te cogner toutes les notions de programmation objet - ce qui en soit
est
Pour la programmation objet, c'est loin d'etre un probleme, je connais deja.
> Pourquoi "Access (Windows oblige)" ??? Il existe d'autres moteurs de bases
de données! Selon le budget et les besoins exacts, je verrais bien Access,
Postgres ou SQL Serveur dans ton cas (Access rique d'être limite si tu a
plus de ~ 10 connections simultanées).
Windows oblige, car il est imposé! Aprés...Access...car pourquoi pas! :-)
Et aucune chance d'avoir plus de dix connexions simultanées
Enfin le plus important, si tu choisis l'option ASP.NET, tu va être obligé
de te cogner toutes les notions de programmation objet - ce qui en soit
est
Pour la programmation objet, c'est loin d'etre un probleme, je connais deja.
> Pourquoi "Access (Windows oblige)" ??? Il existe d'autres moteurs de bases de données! Selon le budget et les besoins exacts, je verrais bien Access, Postgres ou SQL Serveur dans ton cas (Access rique d'être limite si tu a plus de ~ 10 connections simultanées).
Windows oblige, car il est imposé! Aprés...Access...car pourquoi pas! :-) Et aucune chance d'avoir plus de dix connexions simultanées
Enfin le plus important, si tu choisis l'option ASP.NET, tu va être obligé de te cogner toutes les notions de programmation objet - ce qui en soit
est
Pour la programmation objet, c'est loin d'etre un probleme, je connais deja.
SaadE
> Niveau réseau ? Y'a rien. déclarer un driver odbc au pire. Rien de
méchant. Oki....
WinDev c'est pas mal. Mais si tu connais déjà C++, tu vas gagner un peu de temps. Essayes C++ Builder de borland. Pour l'accès aux BDD tu seras pas déçu.
Ce ne serait pas plus simple avec du Visual C++? produit microsoft, donc peut etre deja des fonctions, des classes, deja definies pour Access?
> Niveau réseau ? Y'a rien. déclarer un driver odbc au pire. Rien de
méchant.
Oki....
WinDev c'est pas mal. Mais si tu connais déjà C++, tu vas gagner un peu de
temps. Essayes C++ Builder de borland. Pour l'accès aux BDD tu seras pas
déçu.
Ce ne serait pas plus simple avec du Visual C++? produit microsoft, donc
peut etre deja des fonctions, des classes, deja definies pour Access?
> Niveau réseau ? Y'a rien. déclarer un driver odbc au pire. Rien de
méchant. Oki....
WinDev c'est pas mal. Mais si tu connais déjà C++, tu vas gagner un peu de temps. Essayes C++ Builder de borland. Pour l'accès aux BDD tu seras pas déçu.
Ce ne serait pas plus simple avec du Visual C++? produit microsoft, donc peut etre deja des fonctions, des classes, deja definies pour Access?
SaadE
Toutes vos reponses sont appreciés.... Je tenais a vous remercier tous.
S
Toutes vos reponses sont appreciés....
Je tenais a vous remercier tous.
Toutes vos reponses sont appreciés.... Je tenais a vous remercier tous.
S
Thierry
Bonjour,
Arnaud Debaene a écrit :
Par contre la structure de la base rique d'être relativement complexe, et là l'abscence de jointures, de contrôle d'intégrité référentielle, de tiggers et de procédures stockées - bref tout ce qui manque à MySQL pour être un "vrai" SGBD - risque d'être problématique.
Si, un vrai SGBD si je ne m'abuse. Par contre pas un SGBDR.
-- "MOI JE VEUX JOUER DE L'HELICON (PON PON PON PON)"
Bonjour,
Arnaud Debaene a écrit :
Par contre la structure de la base rique d'être relativement complexe,
et là l'abscence de jointures, de contrôle d'intégrité référentielle,
de tiggers et de procédures stockées - bref tout ce qui manque à MySQL
pour être un "vrai" SGBD - risque d'être problématique.
Si, un vrai SGBD si je ne m'abuse. Par contre pas un SGBDR.
--
"MOI JE VEUX JOUER DE L'HELICON (PON PON PON PON)"
Par contre la structure de la base rique d'être relativement complexe, et là l'abscence de jointures, de contrôle d'intégrité référentielle, de tiggers et de procédures stockées - bref tout ce qui manque à MySQL pour être un "vrai" SGBD - risque d'être problématique.
Si, un vrai SGBD si je ne m'abuse. Par contre pas un SGBDR.
-- "MOI JE VEUX JOUER DE L'HELICON (PON PON PON PON)"
