Bonjour,
Je pose une question assez générale sur l'éventuelle utilité de la
conversion de classeur Excel en base de données, mais surtout, comment
organiser ces données.
Je m'explique :
Au boulot nous avons plusieurs fichiers Excel, dans lesquels les données
des ventes sont classées à peu près de la même façon, par ex. le
classeur des ventes annuelles :
- une feuille par année
- sur chaque feuille (année) plusieurs tableaux : un par point de vente,
et par type de chiffres (Chiffre d'affaire, Nombre de commandes, valeur
moyenne, etc.), tout ça par mois (ou semaines sur un autre classeur).
Les problèmes de tous ces tableaux dans une seule feuille :
- l'affichage n'est pas très pratique, les responsables de chaque point
de vente ne sont pas forcément intéressés par les chiffres des autres
(juste pour comparaison, et encore)
- il est en fait inutile d'avoir des données qui remontent à aussi loin
la plupart du temps (de 2001 à 2007 jusqu'ici, les années antérieures
sont encore sur papier, non saisies). On regarde les autres années juste
pour avoir l'évolution
- dans son format actuel, il est assez difficile de faire des tableaux
de comparaison ou des graphes entre deux ou plusieurs années, entre deux
points de vente, quand il le faut, je recopie en fait les données qui
m'intéressent dans un autre tableau, et je fais mon comparatif ou mon
graphique à partir de là.
- le classeur commence à être un peu trop encombré à mon goût...
- il faut envoyer les fichiers par mails chaque fin de mois, ce qui
encombre un peu le serveur de mail car personne n'efface les messages ou
les pièces jointes
D'où l'idée de réorganiser tout ça, et je me suis penché sur une base de
données, lue dans une feuille de calcul, ou dans les champs par ex. on
pourrait sélectionner l'année, le point de vente, le type de données à
lire, et tout s'affiche, ou une consultation extrasite en se connectant
sur la base de données, mais je ne sais pas trop comment l'organiser
sans faire de doublons (ma première table était en fait un énorme
tableau reprenant tous les champs des tableaux, encore moins pratique).
Le type de donnée ressemble à :
Année - Mois - point de vente - chiffre (CA, nb de commandes ou moyenne).
Jusque là j'ai :
- une table année, avec un seul champ (2001, 2002, etc.)
- une table mois (numero du mois, nom du mois)
- une table POS (points de ventes), indiquant les différents points de
ventes
- une table CA (chiffre d'affaires) avec un champ année, lié à la table
année, un champ mois, lié à la table mois, un champ POS, lié au point de
vente, et evidemment un champ CA, dans lequel je rentre les ventes.
La liaison avec la table POS est évidente, mais pour la date (année et
mois), l'utilité me semble discutable finalement.
Ma table CA ressemble à ma première mouture :
toujours la même année, on tourne les mois, un POS, et le chiffre.
Ensuite on change l'année, mois même POS, etc. Ensuite, je recommence en
changeant le point de vente, etc... Ce qui me fait au final un énorme
tableau.
Donc je me demandais si mon organisation était correcte dans le cadre
d'une base de données, ou si je devais faire une table par point de
vente (champs années, mois, CA, Commandes...)
ou encore une table par année (ce qui revient à mon classeur excel)
ou une table par point de vente et par année.
Evidemment un professionnel pourrait nous faire ça, mais moyens limités,
et l'idée n'est pas prioritaire pour le patron, et j'aimerais apprendre
tout ça. Logiciels utilisés : Access, Excel, OpenOffice (Base et Calc),
éventuellement MySQL. Mon choix n'est pas encore arrêté, je voudrais
déjà savoir organiser et construire ma base avant.
Désolé pour la longueur du message, et merci pour toute aide que vous
pourriez m'apporter (si vous avez réussi à me suivre dans tout mon bla-bla).
Et bien juste pour info une licence Paradox avec le runtime illimité (si tu veux développer une solution et l'installer sur d'autres postes) c'est 150 Euros TTC ! Bon c'est pas open source et Corel/Borland (les co-détenteurs) ne font pas évoluer le produit. Tout juste s'ils le supportent :-(. Lui te permet de te connecter à MySql (ou autre) en 5 mn. Si tu veux voir la simplicité de développement avec cet outil jette un coup d'oeil sur mon tuto (orienté développement et non utilisation interactive mais je montre la création des états sans une ligne de code): http://www.clairinfo.fr/scripts/trace.php?noart=1
Et bien juste pour info une licence Paradox avec le runtime illimité (si tu veux
développer une solution et l'installer sur d'autres postes) c'est 150 Euros TTC
!
Bon c'est pas open source et Corel/Borland (les co-détenteurs) ne font pas
évoluer le produit. Tout juste s'ils le supportent :-(. Lui te permet de te
connecter à MySql (ou autre) en 5 mn.
Si tu veux voir la simplicité de développement avec cet outil jette un coup
d'oeil sur mon tuto (orienté développement et non utilisation interactive mais
je montre la création des états sans une ligne de code):
http://www.clairinfo.fr/scripts/trace.php?noart=1
Et bien juste pour info une licence Paradox avec le runtime illimité (si tu veux développer une solution et l'installer sur d'autres postes) c'est 150 Euros TTC ! Bon c'est pas open source et Corel/Borland (les co-détenteurs) ne font pas évoluer le produit. Tout juste s'ils le supportent :-(. Lui te permet de te connecter à MySql (ou autre) en 5 mn. Si tu veux voir la simplicité de développement avec cet outil jette un coup d'oeil sur mon tuto (orienté développement et non utilisation interactive mais je montre la création des états sans une ligne de code): http://www.clairinfo.fr/scripts/trace.php?noart=1
|-| /-\\ |_ \(\)7 [°¿°]
Bonjour !
Je précise un autre petit avantage de Paradox : il permet d'utiliser simultanément (dans une même requête par exemple), des tables de plusieurs bases distantes et/ou locale.
C'est parfois bien utile de croiser une appli locale, et une appli distante. Et puis, on peut s'en servir pour transférer des data entre bases hétérogènes.
@+
MCI
Bonjour !
Je précise un autre petit avantage de Paradox : il permet d'utiliser
simultanément (dans une même requête par exemple), des tables de plusieurs
bases distantes et/ou locale.
C'est parfois bien utile de croiser une appli locale, et une appli distante.
Et puis, on peut s'en servir pour transférer des data entre bases
hétérogènes.
Je précise un autre petit avantage de Paradox : il permet d'utiliser simultanément (dans une même requête par exemple), des tables de plusieurs bases distantes et/ou locale.
C'est parfois bien utile de croiser une appli locale, et une appli distante. Et puis, on peut s'en servir pour transférer des data entre bases hétérogènes.
@+
MCI
Mo2
Côme de Christen a écrit :
Et bien juste pour info une licence Paradox avec le runtime illimité (si tu veux développer une solution et l'installer sur d'autres postes) c'est 150 Euros TTC ! Bon c'est pas open source et Corel/Borland (les co-détenteurs) ne font pas évoluer le produit. Tout juste s'ils le supportent :-(. Lui te permet de te connecter à MySql (ou autre) en 5 mn. Si tu veux voir la simplicité de développement avec cet outil jette un coup d'oeil sur mon tuto (orienté développement et non utilisation interactive mais je montre la création des états sans une ligne de code): http://www.clairinfo.fr/scripts/trace.php?noart=1
A dire vrai, je ne connais pas du tout Paradox (j'avoue...) :) Mais en effet la licence m'a l'air beaucoup plus raisonnable que Crystal objects ou reports, plus dans notre budget informatique, vu qu'on n'en a pas :) Je ne cherche pas forcément dans l'open source, mais dans les prix raisonnables (Aaah! pognon quand tu nous tiens....) Le tuto est plutôt clair en comparaison de certains que j'ai pu voir jusque là, et surtout la logique des choses est bien expliquée, comme pourquoi stocker une donnée qui peut être recalculée (un total) à partir des données a priori réellement intéressantes (par ex. dans mon cas le total de l'année, alors que je ne stocke que les données par mois)? Ben en fait c'est vrai que cela simplifie énormément la récupération des données. Il faut cependant que cela reste pertinent, et reste à éviter de stocker tout et n'importe quoi. Et le truc de la table qui sert de compteur (pour l'id de facture), c'est pas bête. Retrouver le dernier enregistrement pour un pos donné m'obligeait à scanner toute ma table (ensemble année+mois+pos). Maintenant à l'insertion d'un nouvel enregistrement, j'écris la date dans une table, et en fait cette date est lue lorsque je veux rentrer une nouvelle donnée. Le problème de mon truc c'est que cette table (LastRecord) contient un champ pour chaque POS, ce qui veut dire que si on crée un nouveau POS, il faudra manuellement créer un nouveau champ dans cette table (si on supprime un POS on ne change rien car on gardera quand même les données). A moins qu'il ne soit possible d'avoir des champs dynamiques dans une table? table LastRecord (Last, Pos_Id) table POS(Pos_Id, Pos_Soc, Pos_Name, Pos_Adrs, Pos_Tel, etc.) L'idée d'inclure un nouveau champ dynamiquement c'est surtout pour éviter d'avoir à manipuler la base de données directement. Bon maintenant une question sur les types de base : Pour reprendre l'exemple du tutoriel, alors que MySql (et consorts) utilise un serveur qui tourne en permanence, avec une partie au moins de la bdd en mémoire, les bases de type borland (ou db), sont en fait de simples fichiers écrits et lus selon les besoins? Pour une petite base de données cette solution est peut-être préférable non? Cela me fait penser à notre logiciel de paie : il utilise borland interbase. Il n'y a aucun serveur, par contre un répertoire (et une arborescence) avec pleins de fichiers *.db. Ce répertoire est partagé sur le réseau (nécessite donc une configuration correcte du lan avec les partages réseaux, ce qui est a priori plus compliqué qu'un serveur où il faut juste l'ip et un port ouvert), et les données peuvent du coup être lues et modifiées sur un deuxième poste sur lequel il y a le même logiciel. L'utilité d'un simple pilote, ou d'un serveur Sql, ça doit être la taille et l'utilisation de la base de données? Bon en tout cas, merci pour tout, et bon week-end.
Mo2.
Côme de Christen a écrit :
Et bien juste pour info une licence Paradox avec le runtime illimité (si tu veux
développer une solution et l'installer sur d'autres postes) c'est 150 Euros TTC
!
Bon c'est pas open source et Corel/Borland (les co-détenteurs) ne font pas
évoluer le produit. Tout juste s'ils le supportent :-(. Lui te permet de te
connecter à MySql (ou autre) en 5 mn.
Si tu veux voir la simplicité de développement avec cet outil jette un coup
d'oeil sur mon tuto (orienté développement et non utilisation interactive mais
je montre la création des états sans une ligne de code):
http://www.clairinfo.fr/scripts/trace.php?noart=1
A dire vrai, je ne connais pas du tout Paradox (j'avoue...) :)
Mais en effet la licence m'a l'air beaucoup plus raisonnable que Crystal
objects ou reports, plus dans notre budget informatique, vu qu'on n'en a
pas :)
Je ne cherche pas forcément dans l'open source, mais dans les prix
raisonnables (Aaah! pognon quand tu nous tiens....)
Le tuto est plutôt clair en comparaison de certains que j'ai pu voir
jusque là, et surtout la logique des choses est bien expliquée, comme
pourquoi stocker une donnée qui peut être recalculée (un total) à partir
des données a priori réellement intéressantes (par ex. dans mon cas le
total de l'année, alors que je ne stocke que les données par mois)?
Ben en fait c'est vrai que cela simplifie énormément la récupération des
données. Il faut cependant que cela reste pertinent, et reste à éviter
de stocker tout et n'importe quoi.
Et le truc de la table qui sert de compteur (pour l'id de facture),
c'est pas bête. Retrouver le dernier enregistrement pour un pos donné
m'obligeait à scanner toute ma table (ensemble année+mois+pos).
Maintenant à l'insertion d'un nouvel enregistrement, j'écris la date
dans une table, et en fait cette date est lue lorsque je veux rentrer
une nouvelle donnée. Le problème de mon truc c'est que cette table
(LastRecord) contient un champ pour chaque POS, ce qui veut dire que si
on crée un nouveau POS, il faudra manuellement créer un nouveau champ
dans cette table (si on supprime un POS on ne change rien car on gardera
quand même les données). A moins qu'il ne soit possible d'avoir des
champs dynamiques dans une table?
table LastRecord (Last, Pos_Id)
table POS(Pos_Id, Pos_Soc, Pos_Name, Pos_Adrs, Pos_Tel, etc.)
L'idée d'inclure un nouveau champ dynamiquement c'est surtout pour
éviter d'avoir à manipuler la base de données directement.
Bon maintenant une question sur les types de base :
Pour reprendre l'exemple du tutoriel, alors que MySql (et consorts)
utilise un serveur qui tourne en permanence, avec une partie au moins de
la bdd en mémoire, les bases de type borland (ou db), sont en fait de
simples fichiers écrits et lus selon les besoins? Pour une petite base
de données cette solution est peut-être préférable non?
Cela me fait penser à notre logiciel de paie : il utilise borland
interbase. Il n'y a aucun serveur, par contre un répertoire (et une
arborescence) avec pleins de fichiers *.db. Ce répertoire est partagé
sur le réseau (nécessite donc une configuration correcte du lan avec les
partages réseaux, ce qui est a priori plus compliqué qu'un serveur où il
faut juste l'ip et un port ouvert), et les données peuvent du coup être
lues et modifiées sur un deuxième poste sur lequel il y a le même
logiciel. L'utilité d'un simple pilote, ou d'un serveur Sql, ça doit
être la taille et l'utilisation de la base de données?
Bon en tout cas, merci pour tout, et bon week-end.
Et bien juste pour info une licence Paradox avec le runtime illimité (si tu veux développer une solution et l'installer sur d'autres postes) c'est 150 Euros TTC ! Bon c'est pas open source et Corel/Borland (les co-détenteurs) ne font pas évoluer le produit. Tout juste s'ils le supportent :-(. Lui te permet de te connecter à MySql (ou autre) en 5 mn. Si tu veux voir la simplicité de développement avec cet outil jette un coup d'oeil sur mon tuto (orienté développement et non utilisation interactive mais je montre la création des états sans une ligne de code): http://www.clairinfo.fr/scripts/trace.php?noart=1
A dire vrai, je ne connais pas du tout Paradox (j'avoue...) :) Mais en effet la licence m'a l'air beaucoup plus raisonnable que Crystal objects ou reports, plus dans notre budget informatique, vu qu'on n'en a pas :) Je ne cherche pas forcément dans l'open source, mais dans les prix raisonnables (Aaah! pognon quand tu nous tiens....) Le tuto est plutôt clair en comparaison de certains que j'ai pu voir jusque là, et surtout la logique des choses est bien expliquée, comme pourquoi stocker une donnée qui peut être recalculée (un total) à partir des données a priori réellement intéressantes (par ex. dans mon cas le total de l'année, alors que je ne stocke que les données par mois)? Ben en fait c'est vrai que cela simplifie énormément la récupération des données. Il faut cependant que cela reste pertinent, et reste à éviter de stocker tout et n'importe quoi. Et le truc de la table qui sert de compteur (pour l'id de facture), c'est pas bête. Retrouver le dernier enregistrement pour un pos donné m'obligeait à scanner toute ma table (ensemble année+mois+pos). Maintenant à l'insertion d'un nouvel enregistrement, j'écris la date dans une table, et en fait cette date est lue lorsque je veux rentrer une nouvelle donnée. Le problème de mon truc c'est que cette table (LastRecord) contient un champ pour chaque POS, ce qui veut dire que si on crée un nouveau POS, il faudra manuellement créer un nouveau champ dans cette table (si on supprime un POS on ne change rien car on gardera quand même les données). A moins qu'il ne soit possible d'avoir des champs dynamiques dans une table? table LastRecord (Last, Pos_Id) table POS(Pos_Id, Pos_Soc, Pos_Name, Pos_Adrs, Pos_Tel, etc.) L'idée d'inclure un nouveau champ dynamiquement c'est surtout pour éviter d'avoir à manipuler la base de données directement. Bon maintenant une question sur les types de base : Pour reprendre l'exemple du tutoriel, alors que MySql (et consorts) utilise un serveur qui tourne en permanence, avec une partie au moins de la bdd en mémoire, les bases de type borland (ou db), sont en fait de simples fichiers écrits et lus selon les besoins? Pour une petite base de données cette solution est peut-être préférable non? Cela me fait penser à notre logiciel de paie : il utilise borland interbase. Il n'y a aucun serveur, par contre un répertoire (et une arborescence) avec pleins de fichiers *.db. Ce répertoire est partagé sur le réseau (nécessite donc une configuration correcte du lan avec les partages réseaux, ce qui est a priori plus compliqué qu'un serveur où il faut juste l'ip et un port ouvert), et les données peuvent du coup être lues et modifiées sur un deuxième poste sur lequel il y a le même logiciel. L'utilité d'un simple pilote, ou d'un serveur Sql, ça doit être la taille et l'utilisation de la base de données? Bon en tout cas, merci pour tout, et bon week-end.
Mo2.
Côme de Christen
Salut
"Mo2" a écrit dans le message de news: 45f29cc6$0$28538$
A dire vrai, je ne connais pas du tout Paradox (j'avoue...) :)
Je crois que tu l'utilises (le format de fichier par le logiciel) sans le savoir !
Le tuto est plutôt clair en comparaison de certains que j'ai pu voir jusque là, et surtout la logique des choses est bien expliquée
Et bien merci, ce type de tuto prend du temps donc on est content d'avoir des retours positifs.
pourquoi stocker une donnée qui peut être recalculée (un total) à partir des données a priori réellement intéressantes (par ex. dans mon cas le total de l'année, alors que je ne stocke que les données par mois)? Ben en fait c'est vrai que cela simplifie énormément la récupération des données. Il faut cependant que cela reste pertinent, et reste à éviter de stocker tout et n'importe quoi.
Oui le cas de la facture est le cas typique ou il faut dénormaliser. (d'ailleurs tous les logiciels standards de facturation le font). Bon c'est une dénormalisation particulière (stockage de valeur calculée) qui ne remet pas en cause les principes fondamentaux.
Ce dont il faut se méfier ce sont les "compteurs". Pourquoi tant de logiciels de comptabilité intègrent-ils une procédure de "recalcul des soldes" ? Parce qu'ils utilisent des compteurs. Ils stockent les cumuls du compte lors de la saisie des écritures. A mon sens c'est une erreur, il faut utiliser la base de données qui va gentillement nous retourner la donnée cumulée à partir des lignes détail. Accepter des compteurs (je ne parle pas des index autoincrémentés là) sur une base fichier sans transaction, c'est un mauvais choix. La base de données est faite pour cela, donc tant que l'on est pas confronté à des problème de performance il n'y a guère de raison d'accepter des compteurs.
Avec une base client/serveur offrant trigger et transaction les choses se présentent un peu différemment car la mise à jour des compteurs est plus encadrée.
Et le truc de la table qui sert de compteur (pour l'id de facture), c'est pas bête. Retrouver le dernier enregistrement pour un pos donné m'obligeait à scanner toute ma table (ensemble année+mois+pos). Maintenant à l'insertion d'un nouvel enregistrement, j'écris la date dans une table, et en fait cette date est lue lorsque je veux rentrer une nouvelle donnée. Le problème de mon truc c'est que cette table (LastRecord) contient un champ pour chaque POS, ce qui veut dire que si on crée un nouveau POS, il faudra manuellement créer un nouveau champ dans cette table (si on supprime un POS on ne change rien car on gardera quand même les données). A moins qu'il ne soit possible d'avoir des champs dynamiques dans une table? table LastRecord (Last, Pos_Id) table POS(Pos_Id, Pos_Soc, Pos_Name, Pos_Adrs, Pos_Tel, etc.) L'idée d'inclure un nouveau champ dynamiquement c'est surtout pour éviter d'avoir à manipuler la base de données directement
Je n'ai pas bien compris ton souci en fait.
Bon maintenant une question sur les types de base : Pour reprendre l'exemple du tutoriel, alors que MySql (et consorts) utilise un serveur qui tourne en permanence, avec une partie au moins de la bdd en mémoire, les bases de type borland (ou db), sont en fait de simples fichiers écrits et lus selon les besoins? Pour une petite base de données cette solution est peut-être préférable non?
Il n'y a pas de base de type borland. Borland est le nom d'un éditeur de logiciel !
Oui une base client/serveur tourne sur un serveur et offre une logique (traitements, contrôles...) coté serveur. Les bases de données ne "montent" en mémoire que lors des accès.
L'extension db correspond effectivement aux table Paradox (même si d'autres types de fichiers sont en .db), une base donc de type fichier.
Chaque système a des atouts et des inconvénients. L'utlisation d'une base client/serveur complique le développement mais offre des avantages indéniables notamment de stabilité.
Une base fichier comme Paradox peut fonctionner parfaitement pour un petit groupes de users mais plus leurs nombre et les volumes augmentent, plus les performances baissent et les problèmes surviennent. Concrètement au delà de 50 utilisateurs ou/et avec des tables contenants plus de 500 000 lignes on atteint, AMHA, les limites de l'outil.
Maintenant oui j'ai pleins de clients "petites structures" très satisfaits de leur applications Paradox sur base Paradox mais on est loin dans leur cas des limites (50 users/500 000 lignes par table). Si on pense atteindre ou dépasser ces limites il ne faut même pas se poser de question. Il faut partir sur une base client serveur.
Cela me fait penser à notre logiciel de paie : il utilise borland interbase. Il n'y a aucun serveur, par contre un répertoire (et une arborescence) avec pleins de fichiers *.db.
Oui donc pas du tout interbase (un fichier gdb et un logiciel serveur) mais bien du Paradox à priori !
Ce répertoire est partagé sur le réseau (nécessite donc une configuration correcte du lan avec les partages réseaux, ce qui est a priori plus compliqué qu'un serveur où il faut juste l'ip et un port ouvert),
Exact le paramétrage d'une application Paradox est bien plus compliqué et contraignant, aucun doute la dessus. En outre la base ne fonctionnant pas en IP elle ne peut être atteinte directement par internet sans middle tier.
Côme
Salut
"Mo2" <bouchon.mo2@free.fr> a écrit dans le message de news:
45f29cc6$0$28538$426a74cc@news.free.fr...
A dire vrai, je ne connais pas du tout Paradox (j'avoue...) :)
Je crois que tu l'utilises (le format de fichier par le logiciel) sans le savoir
!
Le tuto est plutôt clair en comparaison de certains que j'ai pu voir
jusque là, et surtout la logique des choses est bien expliquée
Et bien merci, ce type de tuto prend du temps donc on est content d'avoir des
retours positifs.
pourquoi stocker une donnée qui peut être recalculée (un total) à partir
des données a priori réellement intéressantes (par ex. dans mon cas le
total de l'année, alors que je ne stocke que les données par mois)?
Ben en fait c'est vrai que cela simplifie énormément la récupération des
données. Il faut cependant que cela reste pertinent, et reste à éviter
de stocker tout et n'importe quoi.
Oui le cas de la facture est le cas typique ou il faut dénormaliser.
(d'ailleurs tous les logiciels standards de facturation le font). Bon c'est une
dénormalisation particulière (stockage de valeur calculée) qui ne remet pas en
cause les principes fondamentaux.
Ce dont il faut se méfier ce sont les "compteurs". Pourquoi tant de logiciels de
comptabilité intègrent-ils une procédure de "recalcul des soldes" ? Parce qu'ils
utilisent des compteurs. Ils stockent les cumuls du compte lors de la saisie des
écritures. A mon sens c'est une erreur, il faut utiliser la base de données qui
va gentillement nous retourner la donnée cumulée à partir des lignes détail.
Accepter des compteurs (je ne parle pas des index autoincrémentés là) sur une
base fichier sans transaction, c'est un mauvais choix. La base de données est
faite pour cela, donc tant que l'on est pas confronté à des problème de
performance il n'y a guère de raison d'accepter des compteurs.
Avec une base client/serveur offrant trigger et transaction les choses se
présentent un peu différemment car la mise à jour des compteurs est plus
encadrée.
Et le truc de la table qui sert de compteur (pour l'id de facture),
c'est pas bête. Retrouver le dernier enregistrement pour un pos donné
m'obligeait à scanner toute ma table (ensemble année+mois+pos).
Maintenant à l'insertion d'un nouvel enregistrement, j'écris la date
dans une table, et en fait cette date est lue lorsque je veux rentrer
une nouvelle donnée. Le problème de mon truc c'est que cette table
(LastRecord) contient un champ pour chaque POS, ce qui veut dire que si
on crée un nouveau POS, il faudra manuellement créer un nouveau champ
dans cette table (si on supprime un POS on ne change rien car on gardera
quand même les données). A moins qu'il ne soit possible d'avoir des
champs dynamiques dans une table?
table LastRecord (Last, Pos_Id)
table POS(Pos_Id, Pos_Soc, Pos_Name, Pos_Adrs, Pos_Tel, etc.)
L'idée d'inclure un nouveau champ dynamiquement c'est surtout pour
éviter d'avoir à manipuler la base de données directement
Je n'ai pas bien compris ton souci en fait.
Bon maintenant une question sur les types de base :
Pour reprendre l'exemple du tutoriel, alors que MySql (et consorts)
utilise un serveur qui tourne en permanence, avec une partie au moins de
la bdd en mémoire, les bases de type borland (ou db), sont en fait de
simples fichiers écrits et lus selon les besoins? Pour une petite base
de données cette solution est peut-être préférable non?
Il n'y a pas de base de type borland. Borland est le nom d'un éditeur de
logiciel !
Oui une base client/serveur tourne sur un serveur et offre une logique
(traitements, contrôles...) coté serveur. Les bases de données ne "montent" en
mémoire que lors des accès.
L'extension db correspond effectivement aux table Paradox (même si d'autres
types de fichiers sont en .db), une base donc de type fichier.
Chaque système a des atouts et des inconvénients. L'utlisation d'une base
client/serveur complique le développement mais offre des avantages indéniables
notamment de stabilité.
Une base fichier comme Paradox peut fonctionner parfaitement pour un petit
groupes de users mais plus leurs nombre et les volumes augmentent, plus les
performances baissent et les problèmes surviennent. Concrètement au delà de 50
utilisateurs ou/et avec des tables contenants plus de 500 000 lignes on atteint,
AMHA, les limites de l'outil.
Maintenant oui j'ai pleins de clients "petites structures" très satisfaits de
leur applications Paradox sur base Paradox mais on est loin dans leur cas des
limites (50 users/500 000 lignes par table). Si on pense atteindre ou dépasser
ces limites il ne faut même pas se poser de question. Il faut partir sur une
base client serveur.
Cela me fait penser à notre logiciel de paie : il utilise borland
interbase. Il n'y a aucun serveur, par contre un répertoire (et une
arborescence) avec pleins de fichiers *.db.
Oui donc pas du tout interbase (un fichier gdb et un logiciel serveur) mais bien
du Paradox à priori !
Ce répertoire est partagé
sur le réseau (nécessite donc une configuration correcte du lan avec les
partages réseaux, ce qui est a priori plus compliqué qu'un serveur où il
faut juste l'ip et un port ouvert),
Exact le paramétrage d'une application Paradox est bien plus compliqué et
contraignant, aucun doute la dessus. En outre la base ne fonctionnant pas en IP
elle ne peut être atteinte directement par internet sans middle tier.
"Mo2" a écrit dans le message de news: 45f29cc6$0$28538$
A dire vrai, je ne connais pas du tout Paradox (j'avoue...) :)
Je crois que tu l'utilises (le format de fichier par le logiciel) sans le savoir !
Le tuto est plutôt clair en comparaison de certains que j'ai pu voir jusque là, et surtout la logique des choses est bien expliquée
Et bien merci, ce type de tuto prend du temps donc on est content d'avoir des retours positifs.
pourquoi stocker une donnée qui peut être recalculée (un total) à partir des données a priori réellement intéressantes (par ex. dans mon cas le total de l'année, alors que je ne stocke que les données par mois)? Ben en fait c'est vrai que cela simplifie énormément la récupération des données. Il faut cependant que cela reste pertinent, et reste à éviter de stocker tout et n'importe quoi.
Oui le cas de la facture est le cas typique ou il faut dénormaliser. (d'ailleurs tous les logiciels standards de facturation le font). Bon c'est une dénormalisation particulière (stockage de valeur calculée) qui ne remet pas en cause les principes fondamentaux.
Ce dont il faut se méfier ce sont les "compteurs". Pourquoi tant de logiciels de comptabilité intègrent-ils une procédure de "recalcul des soldes" ? Parce qu'ils utilisent des compteurs. Ils stockent les cumuls du compte lors de la saisie des écritures. A mon sens c'est une erreur, il faut utiliser la base de données qui va gentillement nous retourner la donnée cumulée à partir des lignes détail. Accepter des compteurs (je ne parle pas des index autoincrémentés là) sur une base fichier sans transaction, c'est un mauvais choix. La base de données est faite pour cela, donc tant que l'on est pas confronté à des problème de performance il n'y a guère de raison d'accepter des compteurs.
Avec une base client/serveur offrant trigger et transaction les choses se présentent un peu différemment car la mise à jour des compteurs est plus encadrée.
Et le truc de la table qui sert de compteur (pour l'id de facture), c'est pas bête. Retrouver le dernier enregistrement pour un pos donné m'obligeait à scanner toute ma table (ensemble année+mois+pos). Maintenant à l'insertion d'un nouvel enregistrement, j'écris la date dans une table, et en fait cette date est lue lorsque je veux rentrer une nouvelle donnée. Le problème de mon truc c'est que cette table (LastRecord) contient un champ pour chaque POS, ce qui veut dire que si on crée un nouveau POS, il faudra manuellement créer un nouveau champ dans cette table (si on supprime un POS on ne change rien car on gardera quand même les données). A moins qu'il ne soit possible d'avoir des champs dynamiques dans une table? table LastRecord (Last, Pos_Id) table POS(Pos_Id, Pos_Soc, Pos_Name, Pos_Adrs, Pos_Tel, etc.) L'idée d'inclure un nouveau champ dynamiquement c'est surtout pour éviter d'avoir à manipuler la base de données directement
Je n'ai pas bien compris ton souci en fait.
Bon maintenant une question sur les types de base : Pour reprendre l'exemple du tutoriel, alors que MySql (et consorts) utilise un serveur qui tourne en permanence, avec une partie au moins de la bdd en mémoire, les bases de type borland (ou db), sont en fait de simples fichiers écrits et lus selon les besoins? Pour une petite base de données cette solution est peut-être préférable non?
Il n'y a pas de base de type borland. Borland est le nom d'un éditeur de logiciel !
Oui une base client/serveur tourne sur un serveur et offre une logique (traitements, contrôles...) coté serveur. Les bases de données ne "montent" en mémoire que lors des accès.
L'extension db correspond effectivement aux table Paradox (même si d'autres types de fichiers sont en .db), une base donc de type fichier.
Chaque système a des atouts et des inconvénients. L'utlisation d'une base client/serveur complique le développement mais offre des avantages indéniables notamment de stabilité.
Une base fichier comme Paradox peut fonctionner parfaitement pour un petit groupes de users mais plus leurs nombre et les volumes augmentent, plus les performances baissent et les problèmes surviennent. Concrètement au delà de 50 utilisateurs ou/et avec des tables contenants plus de 500 000 lignes on atteint, AMHA, les limites de l'outil.
Maintenant oui j'ai pleins de clients "petites structures" très satisfaits de leur applications Paradox sur base Paradox mais on est loin dans leur cas des limites (50 users/500 000 lignes par table). Si on pense atteindre ou dépasser ces limites il ne faut même pas se poser de question. Il faut partir sur une base client serveur.
Cela me fait penser à notre logiciel de paie : il utilise borland interbase. Il n'y a aucun serveur, par contre un répertoire (et une arborescence) avec pleins de fichiers *.db.
Oui donc pas du tout interbase (un fichier gdb et un logiciel serveur) mais bien du Paradox à priori !
Ce répertoire est partagé sur le réseau (nécessite donc une configuration correcte du lan avec les partages réseaux, ce qui est a priori plus compliqué qu'un serveur où il faut juste l'ip et un port ouvert),
Exact le paramétrage d'une application Paradox est bien plus compliqué et contraignant, aucun doute la dessus. En outre la base ne fonctionnant pas en IP elle ne peut être atteinte directement par internet sans middle tier.
Côme
Jean-Marc Molina
Jogo wrote:
Elles ne servent effectivement à rien. Une table modélise une relation entre des données. Si vous n'avez qu'une seule donnée, ça ne sert à rien de faire une table. Même la table des points de vente ne sert à rien si elle n'associe pas d'autres données à chaque point de vente (adresse, responsable etc...).
Je pense que la table des PV est nécessaire car il s'agit d'un objet bien distinct du chiffre d'affaire. De plus un même PV a plusieurs chiffres d'affaire. Sans compter qu'une mauvaise saisie du nom du PV peut entraîner des incohérences dans la base. En séparant les PV des CA on assure une meilleure intégrité des données et une architecture plus souple à la base. Par exemple les PV pourraient être utilisés pour d'autres données que le CA.
Jogo wrote:
Elles ne servent effectivement à rien. Une table modélise une relation
entre des données. Si vous n'avez qu'une seule donnée, ça ne sert à
rien de faire une table. Même la table des points de vente ne sert à
rien si elle n'associe pas d'autres données à chaque point de vente
(adresse, responsable etc...).
Je pense que la table des PV est nécessaire car il s'agit d'un objet bien
distinct du chiffre d'affaire. De plus un même PV a plusieurs chiffres
d'affaire. Sans compter qu'une mauvaise saisie du nom du PV peut entraîner
des incohérences dans la base. En séparant les PV des CA on assure une
meilleure intégrité des données et une architecture plus souple à la base.
Par exemple les PV pourraient être utilisés pour d'autres données que le CA.
Elles ne servent effectivement à rien. Une table modélise une relation entre des données. Si vous n'avez qu'une seule donnée, ça ne sert à rien de faire une table. Même la table des points de vente ne sert à rien si elle n'associe pas d'autres données à chaque point de vente (adresse, responsable etc...).
Je pense que la table des PV est nécessaire car il s'agit d'un objet bien distinct du chiffre d'affaire. De plus un même PV a plusieurs chiffres d'affaire. Sans compter qu'une mauvaise saisie du nom du PV peut entraîner des incohérences dans la base. En séparant les PV des CA on assure une meilleure intégrité des données et une architecture plus souple à la base. Par exemple les PV pourraient être utilisés pour d'autres données que le CA.
Jean-Marc Molina
Mo2 wrote:
Comme quoi on devrait réfléchir sérieusement aux outils qu'on met en place, pour avoir des solutions pérennes, même dans une petite structure comme la nôtre.
Justement je comprends que tu souhaites apprendre à développer ta propre solution mais de là à l'utiliser en milieu professionnel et à la déployer dans toute ton exercice. Si j'étais ton patron je te taperai sur les doigts :). Plus sérieusement je pense qu'au contraire la solution n'est pas "pérenne" et vous devriez plutôt vous tourner vers une solution professionnelle, libre, gratuite ou commerciale peu importe. Vous allez devoir la maintenir vous-mêmes, la solution développée aura des "bugs" et ce problème a déjà été résolu par des milliers d'entreprises car franchement la gestion du CA c'est quand même "la base".
Donc il ne faut pas mélanger intérêt personnel, se former et en apprendre plus sur certains sujets, et intérêts de l'entreprises : coût et délai de gestion, support et assurance proposés par les solutions pro...
Mo2 wrote:
Comme quoi on devrait réfléchir sérieusement aux outils qu'on met en
place, pour avoir des solutions pérennes, même dans une petite
structure comme la nôtre.
Justement je comprends que tu souhaites apprendre à développer ta propre
solution mais de là à l'utiliser en milieu professionnel et à la déployer
dans toute ton exercice. Si j'étais ton patron je te taperai sur les doigts
:). Plus sérieusement je pense qu'au contraire la solution n'est pas
"pérenne" et vous devriez plutôt vous tourner vers une solution
professionnelle, libre, gratuite ou commerciale peu importe. Vous allez
devoir la maintenir vous-mêmes, la solution développée aura des "bugs" et ce
problème a déjà été résolu par des milliers d'entreprises car franchement la
gestion du CA c'est quand même "la base".
Donc il ne faut pas mélanger intérêt personnel, se former et en apprendre
plus sur certains sujets, et intérêts de l'entreprises : coût et délai de
gestion, support et assurance proposés par les solutions pro...
Comme quoi on devrait réfléchir sérieusement aux outils qu'on met en place, pour avoir des solutions pérennes, même dans une petite structure comme la nôtre.
Justement je comprends que tu souhaites apprendre à développer ta propre solution mais de là à l'utiliser en milieu professionnel et à la déployer dans toute ton exercice. Si j'étais ton patron je te taperai sur les doigts :). Plus sérieusement je pense qu'au contraire la solution n'est pas "pérenne" et vous devriez plutôt vous tourner vers une solution professionnelle, libre, gratuite ou commerciale peu importe. Vous allez devoir la maintenir vous-mêmes, la solution développée aura des "bugs" et ce problème a déjà été résolu par des milliers d'entreprises car franchement la gestion du CA c'est quand même "la base".
Donc il ne faut pas mélanger intérêt personnel, se former et en apprendre plus sur certains sujets, et intérêts de l'entreprises : coût et délai de gestion, support et assurance proposés par les solutions pro...
Jean-Marc Molina
Mo2 wrote:
- une table POS (points de vente) : identifiant unique (clé), nom, coordonnées, etc. - une table Chiffres : champ année, champ mois, champ POS en relation avec la table POS, qui reprend l'identifiant unique de la table POS, puis un champ CA (chiffre d'affaire), un champ CMDE (nombre de commandes), un champ Nb_Art (nombre d'articles moyen par commande), et un dernier champ pour la clé primaire.
Dans le cas de l'id de la table POS dans la table Chiffres on parle de clé étrangère. Sinon les champs année et mois devraient être fusionnés en un champ de type DATE (AAAA-MM-JJ). D'ailleurs quel est le type du champ mois ?
Pour le moment je n'ai rentré les données que pour un seul point de vente (520 lignes de données et 7 champs différents). J'ai essayé Base de OpenOffice, mais il y a quelques comportements bizarres (par ex. les données ne sont parfois pas modifiables, il faut fermer le fichier et l'ouvrir à nouveau).
Et vous vous en sortez avec les formulaires de Base ? J'avoue ne pas avoir trop compris comment mettre en page de bons formulaires. On est obligé de dessiner les composants !
Je n'ai pas réussi pour le moment à me connecter à la base de données (Base ou Access) via le réseau, pour consultation sur chaque poste de travail.
Une solution hybride consisterait à dessiner les formulaires avec Base ou Access et à utiliser MySQL comme SGBD, ça se fait simplement à l'aide d'un pilote ODBC. Il faut créer une source de données ou quelque chose d'équivalent dans Base ou Access. L'intérêt de MySQL c'est de centraliser les données sur un serveur unique auquel les clients accèdent. Ça évite de se trimbaler avec des centaines de fichiers. Surtout quand il s'agit de CA. Ça circule dans toute la boîte et tout le monde y a accès. Pas très "secure".
L'inconvénient est évidemment qu'il faut installer un serveur web+php+mysql sur notre intranet (au pire si tout le monde se connecte en même temps, ça fait 10 utilisateurs).
10 utilisateurs c'est vraiment "ridicule" comparé à d'autres systèmes d'information. MySQL peut largement supporter des centaines voire des milliers d'utilisateurs si l'application est bien architecturée. Pour l'installation sur un serveur je ne vois pas trop le problème car des solutions clé en main comme EasyPHP simplifie grandement le "process".
Mo2 wrote:
- une table POS (points de vente) : identifiant unique (clé), nom,
coordonnées, etc.
- une table Chiffres : champ année, champ mois, champ POS en relation
avec la table POS, qui reprend l'identifiant unique de la table POS,
puis un champ CA (chiffre d'affaire), un champ CMDE (nombre de
commandes), un champ Nb_Art (nombre d'articles moyen par commande), et
un dernier champ pour la clé primaire.
Dans le cas de l'id de la table POS dans la table Chiffres on parle de clé
étrangère. Sinon les champs année et mois devraient être fusionnés en un
champ de type DATE (AAAA-MM-JJ). D'ailleurs quel est le type du champ mois ?
Pour le moment je n'ai rentré les données que pour un seul point de
vente (520 lignes de données et 7 champs différents). J'ai essayé Base
de OpenOffice, mais il y a quelques comportements bizarres (par ex.
les données ne sont parfois pas modifiables, il faut fermer le
fichier et l'ouvrir à nouveau).
Et vous vous en sortez avec les formulaires de Base ? J'avoue ne pas avoir
trop compris comment mettre en page de bons formulaires. On est obligé de
dessiner les composants !
Je n'ai pas réussi pour le moment à me connecter à la base de
données (Base ou Access) via le réseau, pour consultation sur chaque
poste de travail.
Une solution hybride consisterait à dessiner les formulaires avec Base ou
Access et à utiliser MySQL comme SGBD, ça se fait simplement à l'aide d'un
pilote ODBC. Il faut créer une source de données ou quelque chose
d'équivalent dans Base ou Access. L'intérêt de MySQL c'est de centraliser
les données sur un serveur unique auquel les clients accèdent. Ça évite de
se trimbaler avec des centaines de fichiers. Surtout quand il s'agit de CA.
Ça circule dans toute la boîte et tout le monde y a accès. Pas très
"secure".
L'inconvénient est évidemment qu'il faut installer un
serveur web+php+mysql sur notre intranet (au
pire si tout le monde se connecte en même temps, ça fait 10
utilisateurs).
10 utilisateurs c'est vraiment "ridicule" comparé à d'autres systèmes
d'information. MySQL peut largement supporter des centaines voire des
milliers d'utilisateurs si l'application est bien architecturée. Pour
l'installation sur un serveur je ne vois pas trop le problème car des
solutions clé en main comme EasyPHP simplifie grandement le "process".
- une table POS (points de vente) : identifiant unique (clé), nom, coordonnées, etc. - une table Chiffres : champ année, champ mois, champ POS en relation avec la table POS, qui reprend l'identifiant unique de la table POS, puis un champ CA (chiffre d'affaire), un champ CMDE (nombre de commandes), un champ Nb_Art (nombre d'articles moyen par commande), et un dernier champ pour la clé primaire.
Dans le cas de l'id de la table POS dans la table Chiffres on parle de clé étrangère. Sinon les champs année et mois devraient être fusionnés en un champ de type DATE (AAAA-MM-JJ). D'ailleurs quel est le type du champ mois ?
Pour le moment je n'ai rentré les données que pour un seul point de vente (520 lignes de données et 7 champs différents). J'ai essayé Base de OpenOffice, mais il y a quelques comportements bizarres (par ex. les données ne sont parfois pas modifiables, il faut fermer le fichier et l'ouvrir à nouveau).
Et vous vous en sortez avec les formulaires de Base ? J'avoue ne pas avoir trop compris comment mettre en page de bons formulaires. On est obligé de dessiner les composants !
Je n'ai pas réussi pour le moment à me connecter à la base de données (Base ou Access) via le réseau, pour consultation sur chaque poste de travail.
Une solution hybride consisterait à dessiner les formulaires avec Base ou Access et à utiliser MySQL comme SGBD, ça se fait simplement à l'aide d'un pilote ODBC. Il faut créer une source de données ou quelque chose d'équivalent dans Base ou Access. L'intérêt de MySQL c'est de centraliser les données sur un serveur unique auquel les clients accèdent. Ça évite de se trimbaler avec des centaines de fichiers. Surtout quand il s'agit de CA. Ça circule dans toute la boîte et tout le monde y a accès. Pas très "secure".
L'inconvénient est évidemment qu'il faut installer un serveur web+php+mysql sur notre intranet (au pire si tout le monde se connecte en même temps, ça fait 10 utilisateurs).
10 utilisateurs c'est vraiment "ridicule" comparé à d'autres systèmes d'information. MySQL peut largement supporter des centaines voire des milliers d'utilisateurs si l'application est bien architecturée. Pour l'installation sur un serveur je ne vois pas trop le problème car des solutions clé en main comme EasyPHP simplifie grandement le "process".
Jean-Marc Molina
Mihamina (R12y) Rakotomandimby wrote:
Si ton patron a une quelconque perspective de croissance, alors dis-lui qu'il doit songer à la scalabilité. Tu peu lui faire remarquer que si par contre il ne pense pas "scalabilité", c'est qu'il ne compte pas s'agrandir... ;-)
En effet la solution OOo/Access/MySQL ne me semble pas assez flexible et son déploiement risque de poser problème sur les nouveaux postes. Sans parler des mises à jour à effectuer. D'ailleurs je ne vois pas pourquoi tout le monde a besoin d'avoir tout ce petit monde d'installé. Le mieux serait de générer des rapports et de les soumettre sur l'intranet sous la forme de documents PDF par exemple. En schématisant on pourrait dire que seuls le comptable et le patron ont accès à ces données, les autres employés se contentant de consulter les rapports mensuels et annuels.
Mihamina (R12y) Rakotomandimby wrote:
Si ton patron a une quelconque perspective de croissance, alors
dis-lui qu'il doit songer à la scalabilité.
Tu peu lui faire remarquer que si par contre il ne pense pas
"scalabilité", c'est qu'il ne compte pas s'agrandir... ;-)
En effet la solution OOo/Access/MySQL ne me semble pas assez flexible et son
déploiement risque de poser problème sur les nouveaux postes. Sans parler
des mises à jour à effectuer. D'ailleurs je ne vois pas pourquoi tout le
monde a besoin d'avoir tout ce petit monde d'installé. Le mieux serait de
générer des rapports et de les soumettre sur l'intranet sous la forme de
documents PDF par exemple. En schématisant on pourrait dire que seuls le
comptable et le patron ont accès à ces données, les autres employés se
contentant de consulter les rapports mensuels et annuels.
Si ton patron a une quelconque perspective de croissance, alors dis-lui qu'il doit songer à la scalabilité. Tu peu lui faire remarquer que si par contre il ne pense pas "scalabilité", c'est qu'il ne compte pas s'agrandir... ;-)
En effet la solution OOo/Access/MySQL ne me semble pas assez flexible et son déploiement risque de poser problème sur les nouveaux postes. Sans parler des mises à jour à effectuer. D'ailleurs je ne vois pas pourquoi tout le monde a besoin d'avoir tout ce petit monde d'installé. Le mieux serait de générer des rapports et de les soumettre sur l'intranet sous la forme de documents PDF par exemple. En schématisant on pourrait dire que seuls le comptable et le patron ont accès à ces données, les autres employés se contentant de consulter les rapports mensuels et annuels.
Jean-Marc Molina
Mo2 wrote:
Et pour le moment le seul moyen que j'ai d'exploiter les requêtes sql est de mettre ça dans une page web (php). Ca ce n'est pas moi qui le fait mais un ami. Un script php pour rentrer les données en renseignant le pos et la date (il sugère automatiquement la date du nouvel enregistrement en se basant sur la dernière enregistrée), et un autre qui affiche les données en choisissant le pos, et des critères de dates. C'est exactement ce que je voudrais faire sous excel (ou calc), car de là je pourrais aussi tracer des graphes par ex.(chose beaucoup plus compliquée à faire en php). A moins qu'il n'existe une autre façon pas trop compliquée d'utiliser les données d'une base de données (interface, frontend, ?)?
J'ai l'impression que vous voulez tout faire vous même et je pense que c'est une erreur. Vous devriez chercher l'équilibre entre : * On se fait plaisir en développant quelques petits trucs maison * On utiliser des solutions clé en main comme le "package" de Image_Graph [1] pour générer nos beaux diagrammes
D'après vos questions vous semblez débuter et je trouve que vouloir tout faire est un peu trop gourmand. Il faut mieux se plier aux compromis et réussir à terminer les choses. À trop vouloir tout faire on finit par ne plus rien faire du tout. À ce rythme votre patron optera pour une solution pro dans 2 ans une fois que tout le monde aura constaté dans quelle impasse les formulaires, les fichiers Excel, les graphes, la base MySQL... vous ont conduit. Je vois un gros problème de maintenance dans tout ça. Je n'ose même pas imaginer ce qui arrivera à votre boîte si vous partez sans avoir documenté tout ce petit monde. Il vous faudrait une tierce personne pour équilibrer le débat et permettre à votre patron de prendre la bonne décision.
Et pour le moment le seul moyen que j'ai d'exploiter les
requêtes sql est de mettre ça dans une page web (php). Ca ce n'est
pas moi qui le fait mais un ami. Un script php pour rentrer les
données en renseignant le pos et la date (il sugère automatiquement
la date du nouvel enregistrement en se basant sur la dernière
enregistrée), et un autre qui affiche les données en choisissant le
pos, et des critères de dates. C'est exactement ce que je voudrais
faire sous excel (ou calc), car de là je pourrais aussi tracer des
graphes par ex.(chose beaucoup plus compliquée à faire en php).
A moins qu'il n'existe une autre façon pas trop compliquée d'utiliser
les données d'une base de données (interface, frontend, ?)?
J'ai l'impression que vous voulez tout faire vous même et je pense que c'est
une erreur. Vous devriez chercher l'équilibre entre :
* On se fait plaisir en développant quelques petits trucs maison
* On utiliser des solutions clé en main comme le "package" de Image_Graph
[1] pour générer nos beaux diagrammes
D'après vos questions vous semblez débuter et je trouve que vouloir tout
faire est un peu trop gourmand. Il faut mieux se plier aux compromis et
réussir à terminer les choses. À trop vouloir tout faire on finit par ne
plus rien faire du tout. À ce rythme votre patron optera pour une solution
pro dans 2 ans une fois que tout le monde aura constaté dans quelle impasse
les formulaires, les fichiers Excel, les graphes, la base MySQL... vous ont
conduit. Je vois un gros problème de maintenance dans tout ça. Je n'ose même
pas imaginer ce qui arrivera à votre boîte si vous partez sans avoir
documenté tout ce petit monde. Il vous faudrait une tierce personne pour
équilibrer le débat et permettre à votre patron de prendre la bonne
décision.
Et pour le moment le seul moyen que j'ai d'exploiter les requêtes sql est de mettre ça dans une page web (php). Ca ce n'est pas moi qui le fait mais un ami. Un script php pour rentrer les données en renseignant le pos et la date (il sugère automatiquement la date du nouvel enregistrement en se basant sur la dernière enregistrée), et un autre qui affiche les données en choisissant le pos, et des critères de dates. C'est exactement ce que je voudrais faire sous excel (ou calc), car de là je pourrais aussi tracer des graphes par ex.(chose beaucoup plus compliquée à faire en php). A moins qu'il n'existe une autre façon pas trop compliquée d'utiliser les données d'une base de données (interface, frontend, ?)?
J'ai l'impression que vous voulez tout faire vous même et je pense que c'est une erreur. Vous devriez chercher l'équilibre entre : * On se fait plaisir en développant quelques petits trucs maison * On utiliser des solutions clé en main comme le "package" de Image_Graph [1] pour générer nos beaux diagrammes
D'après vos questions vous semblez débuter et je trouve que vouloir tout faire est un peu trop gourmand. Il faut mieux se plier aux compromis et réussir à terminer les choses. À trop vouloir tout faire on finit par ne plus rien faire du tout. À ce rythme votre patron optera pour une solution pro dans 2 ans une fois que tout le monde aura constaté dans quelle impasse les formulaires, les fichiers Excel, les graphes, la base MySQL... vous ont conduit. Je vois un gros problème de maintenance dans tout ça. Je n'ose même pas imaginer ce qui arrivera à votre boîte si vous partez sans avoir documenté tout ce petit monde. Il vous faudrait une tierce personne pour équilibrer le débat et permettre à votre patron de prendre la bonne décision.
Si la construction est propre il sera très facile de faire évoluer sa solution le cas échéant. La vraie question est : est-ce qu'un "power user" Excel / Access... non développeur peut construire quelque chose de propre ? Je crois honnêtement que non. Par contre rien ne l'empêche de se former si le sujet l'intéresse ou demander de l'aide comme ici.
Entièrement d'accord, il ne faut pas faire passer ses intérêts personnels avant ceux de l'entreprise. Surtout dans une petite structure, on a pas d'argent à jeter par les fenêtres !
Côme de Christen wrote:
Si la construction est propre il sera très facile de faire
évoluer sa solution le cas échéant. La vraie question est : est-ce
qu'un "power user" Excel / Access... non développeur peut construire
quelque chose de propre ? Je crois honnêtement que non. Par contre
rien ne l'empêche de se former si le sujet l'intéresse ou demander de
l'aide comme ici.
Entièrement d'accord, il ne faut pas faire passer ses intérêts personnels
avant ceux de l'entreprise. Surtout dans une petite structure, on a pas
d'argent à jeter par les fenêtres !
Si la construction est propre il sera très facile de faire évoluer sa solution le cas échéant. La vraie question est : est-ce qu'un "power user" Excel / Access... non développeur peut construire quelque chose de propre ? Je crois honnêtement que non. Par contre rien ne l'empêche de se former si le sujet l'intéresse ou demander de l'aide comme ici.
Entièrement d'accord, il ne faut pas faire passer ses intérêts personnels avant ceux de l'entreprise. Surtout dans une petite structure, on a pas d'argent à jeter par les fenêtres !
