Aide sur l'organisation d'une BDD

Le
Mo2
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).

Mo2.
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
Jogo
Le #21872521
Sur fr.comp.applications.sgbd, Mo2 disait :

- 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.



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...).

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.



Pas de souci. C'est exactement à ça que servent les bases de données :
gérer de grandes quantités de données. Il suffira ensuite de ne
sélectionner que certaines lignes, pour avoir un tableau de taille
raisonnable.

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...)



Non.

ou encore une table par année (ce qui revient à mon classeur excel)



Encore non.

ou une table par point de vente et par année.



Toujours non. Toutes ces "sous-tables" seront le résultat des SELECT.

Bref, n'avoir qu'une seule grosse table n'est pas forcement une
mauvaise idée.

--
Il n'est personne aujourd'hui, de vraiment cultivé,
pour parlé de la beauté d'un couché de soleil.
-- Wilde
Mo2
Le #21872491
Jogo a écrit :
Sur fr.comp.applications.sgbd, Mo2 disait :

- 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.



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...).

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.



Pas de souci. C'est exactement à ça que servent les bases de données :
gérer de grandes quantités de données. Il suffira ensuite de ne
sélectionner que certaines lignes, pour avoir un tableau de taille
raisonnable.

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...)



Non.

ou encore une table par année (ce qui revient à mon classeur excel)



Encore non.

ou une table par point de vente et par année.



Toujours non. Toutes ces "sous-tables" seront le résultat des SELECT.

Bref, n'avoir qu'une seule grosse table n'est pas forcement une
mauvaise idée.




Merci bien pour les renseignements.
En effet ma table points de vente inclut les divers renseignements :
raison sociale, nom, adresse, téléphone, etc.
Supprimer mes tables pour les dates m'arrange, parce que j'ai du mal à
faire la relation avec les champs de date de ma table chiffre d'affaire
(par ex. les années sont correctement enregistrées dans la table Année,
mais elles changent de valeurs dans la table CA (127, -48, etc. au lieu
de 2001, 2002), alors que les formats sont les mêmes).
J'ai donc pour le moment dans ma base :
- 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.

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). Par contre les interrogations me semblent plus
faciles (ou mieux expliquées) qu'avec Access, même si un peu plus
lentes. 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.
J'ai également fait un test avec MySQL, et un ami m'a fait un formulaire
tout bête (pas de mise en page, il ne retourne que les valeurs brutes en
choisissant l'année et le point de vente) en php sur un serveur test sur
notre intranet. Cette solution me plaît davantage car il est possible
d'avoir un utilisateur qui peut entrer et modifier les données, et un
autre générique juste pour les consulter. 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).
J'ai encore à apprendre, mais je me dirige pour le moment vers un
serveur MySQL, et OpenOffice pour faire les formulaires, avec Calc pour
récupérer les données et les traiter. Cela implique d'installer Ooo sur
nos postes, mais de toutes façons il en était vaguement question car
nous devrons bientôt changer le matériel, et le problème du coût des
licences est déjà posé.

Je suis preneuse de toute suggestion :)

Merci.
Mihamina (R12y) Rakotomandimby
Le #21872421
Mo2 wrote:

J'ai également fait un test avec MySQL



Ne pas oublié PostGreSQL si tu as encore le temps.
Mo2
Le #21872411
Mihamina (R12y) Rakotomandimby a écrit :
Mo2 wrote:

J'ai également fait un test avec MySQL



Ne pas oublié PostGreSQL si tu as encore le temps.



J'ai le temps, encore que je préférerais que ce soit fait rapidement
(chaque semaine des données à rajouter, sans arrêt, pff...)
PostGreSQL semble plus complexe à mettre en oeuvre que MySQL (qui peut
être installé facilement avec des packages tous prêts sur un
environnement Windows). J'ai commencé à lire le site français de
PostgreSql, tout semble plutôt expliqué pour les systèmes unix-linux, et
on travaille sous windows. Comme la base de données est petite, avec peu
d'utilisateurs, je pense rester à MySql sous windows. Par contre le site
français de PostGreSQL donne tout un tas d'exemples de commandes Sql,
intéressant, même si je présume qu'il doit y avoir des différences.
J'ai fait une petite démo au patron, et il semble intéressé finalement,
si j'arrive à faire mes tableaux comparatifs et mes graphiques sous
Excel ou Calc, même s'il n'est pas prêt à investir de l'argent là-dedans
(le contraire aurait été étonnant :p ).
Pour comparaison :
- classeurs Excel actuels : 9 fichiers pour un total de près de 12Mo, à
mettre à jour chacun le dernier jour du mois (avec beaucoup de données
identiques d'un classeur à l'autre).
- tout ça à envoyer à 10 personnes différentes chaque début de mois.
- j'ai fait une petite recherche sur notre (minuscule) serveur de
courriers pour notre réseau interne, et j'ai trouvé une taille totale de
3,10 Go juste pour les pièces jointes (normalement uniquement ces
classeurs, rarement effacés), ceci sans compter le nombre de fois où les
classeurs ont été envoyés via notre fai.
- base de données : 3Mo (estimation large)
- classeurs et formulaires pour la consultation des données de la base :
100Ko maximum apparemment (fichiers enregistrés sur chaque poste de
travail une fois pour toute).
- la mise à jour des données devrait me prendre 3 à 4 fois moins de
temps (pour le moment 3/4h pour tous les points de vente, lorsque j'ai
les papiers à temps), à cause des données redondantes essentiellement,
et la manipulation des fichiers, des feuilles...

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.

Mo2
Mihamina (R12y) Rakotomandimby
Le #21872361
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.



Je viens d'intervenir dans une structure qui initialement était petite (2
personnes) et qui maintenant en compte 20 (employés).
Je peu te dire que le système informatique est complètement mal foutu.
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... ;-)
Côme de Christen
Le #21872331
"Mihamina (R12y) Rakotomandimby" le message de news: espedq$2v2o$
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.



Je viens d'intervenir dans une structure qui initialement était petite (2
personnes) et qui maintenant en compte 20 (employés).
Je peu te dire que le système informatique est complètement mal foutu.
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... ;-)



Moui je me méfie en fait de ce raisonnement qui conduit tout droit logiquement à
:

- il faut partir sur une base Oracle (dès fois que la croissance...)
- il faut utiliser SAP pour la gestion (au cas où le groupe deviendrait
international...)

etc...

il me semble que la souplesse doit être primordiale dans une petite structure
afin de suivre rapidement les évolutions. Autant je comprends le service IT d'un
groupe qui va lutter contre la multiplication des petits outils individuels
(Excel,Access...) afin d'éviter un cauchemar pour fusionner et synthétiser tout
cela, autant dans une petite structure sans informaticien je ne vois pas les
choses de la même façon. Ce travail sur Excel/Access... aura permis aux
utilisateurs de jouer librement avec leur données, de tester des présentations,
des tableaux de bord... Une fois ce travail fait et qu'une vision plus pérenne
se dessine sur le système souhaitable alors oui faire appel à une aide extérieur
pour construire quelque chose de propre et surtout d'adapté en terme de
complexité au besoin réel. 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.
Mo2
Le #21872261
Côme de Christen a écrit :
"Mihamina (R12y) Rakotomandimby" le message de news: espedq$2v2o$
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.


Je viens d'intervenir dans une structure qui initialement était petite (2
personnes) et qui maintenant en compte 20 (employés).
Je peu te dire que le système informatique est complètement mal foutu.
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... ;-)



Moui je me méfie en fait de ce raisonnement qui conduit tout droit logiquement à
:

- il faut partir sur une base Oracle (dès fois que la croissance...)
- il faut utiliser SAP pour la gestion (au cas où le groupe deviendrait
international...)

etc...

il me semble que la souplesse doit être primordiale dans une petite structure
afin de suivre rapidement les évolutions. Autant je comprends le service IT d'un
groupe qui va lutter contre la multiplication des petits outils individuels
(Excel,Access...) afin d'éviter un cauchemar pour fusionner et synthétiser tout
cela, autant dans une petite structure sans informaticien je ne vois pas les
choses de la même façon. Ce travail sur Excel/Access... aura permis aux
utilisateurs de jouer librement avec leur données, de tester des présentations,
des tableaux de bord... Une fois ce travail fait et qu'une vision plus pérenne
se dessine sur le système souhaitable alors oui faire appel à une aide extérieur
pour construire quelque chose de propre et surtout d'adapté en terme de
complexité au besoin réel. 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.







C'est un peu ma vision des choses, mais mieux exprimée :))
Il faut dire tout de même que dans les entreprises, si on n'a pas une
petite idée (ou un peu d'imagination) de ce qu'il est possible de faire,
alors on reste avec ses petits outils. J'ai repris le poste comptable il
y a seulement 2 ans, et depuis le début cette façon de faire m'a
dérangé. De toutes façons je ne pense pas me substituer à un ou des
pros. Mais je pense qu'il est préférable d'y réfléchir tant que nous
avons (finalement) encore assez peu de données.
Le plus beau jour de ma vie de comptable a été la découverte des
tableaux croisés dynamiques (si-si), qui permettent de faire assez
simplement les mêmes opérations que je peinais à faire jusque là. Pour
illustrer qu'il faut connaître un peu pour savoir ce qu'on peut faire.
Mon problème actuel est de trouver un moyen maintenant d'utiliser la
base de données (car une base de données toute seule n'a pas beaucoup
d'intérêt), que j'ai fait en triple : Access, Base de Ooo, et MySql (y'a
pas toutes les données, juste le minimum).
Résultat des courses : OpenOffice semble être complètement buggé. Il
perd les connections, plante sur les formulaires, ne retrouve pas les
données, etc. Je fais exactement la même chose sur Access et Excel, et
ça marche. Dommage, j'aurais bien aimé qu'on passe à Ooo, mais
apparemment en utilisation un peu poussée, il n'est pas encore au point.
Je n'arrive pas encore à faire ce que je veux sur le tableur (récupérer
ou enregistrer dynamiquement des données, par ex. en choisissant le
point de vente, la date, etc.) alors qu'en requête sql c'est bon. 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, ?)?

Mo2
Jerome PAULIN
Le #21872251
Mo2 a écrit :

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, ?)?

Mo2



Salut,

Pour l'exploitation des données, tu peux regarder du coté de Crystal
Reports, ca devrait te plaire ...

Il te faudra en plus un petit bout de PHP ou autre (Delphi, Windev, ...)
pour alimenter ta base via des formulaires de saisie.

gg
Côme de Christen
Le #21872241
Salut

"Mo2" 45f154e6$0$31988$
[...]
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, ?)?



MySql est un très bon compromis simplicité / stabilité / performance d'où son
succès logique.
Effectivement ce type de base nécessite un frontend pour un accès confortable.
Pour MySql le choix est tout de même vaste puisqu'il existe un pilote ODBC.
Concrètement tous les produits compatibles ODBC (Access, Paradox...) vont
pouvoir attaquer le serveur SQL en exploitant leurs atouts propres (facilité de
construction de formulaire, de requête, d'états).

J'ai écrit un article sur ce sujet :
http://www.clairinfo.fr/scripts/trace.php?noart (en anglais par contre
désolé) montrant une telle utlisation avec Paradox / MySql.

Sans prétendre que cela soit LA solution c'est une piste intéressante pour une
petite structure :

- choisir une base Sql de stockage (autant rester dans les classiques
connues fiables et ouvertes)
- choisir un front-end simple capable de construire fomulaire, état et
requêtes visuellement (la perle rare, je ne trouve pas malheureusement
l'équivalent de Paradox modernisé)
- utiliser les tableurs en bout de chaine pour des présentations libres et
les graphes

Ce dont il faut se méfier, je trouve, ce sont les conseils de techniciens purs
qui ne veulent pas comprendre le vrai souci légitime d'un utilisateur d'accéder
librement et facilement à toutes ses données. SQL (le langage) n'est pas la
panacée loin de là pour un utilisaeur. Si l'on sort de ce sentier sans
compétence informatique interne on est un peu condamné à utiliser des logiciels
standards ou à sous-traiter le développement et l'on retombe dans la perte
d'autonomie plus ou moins forte en fonction de la complexité de la base et du
frontend choisi.

L'évolution "appli web" que nous constatons a eu jusqu'ici plutôt tendance à
compliquer le développement qu'à le simplifier (mélange de langages et de
syntaxe notamment) Il faut espérer que cela change et que l'on puisse échapper
aux énormes framework usines à gaz à la mode actuellement. Puisque tu évoquais
Php (un langage au succès bien mérité là aussi de part sa simplicité d'accès) on
commence à percevoir des outils qui vont dans la bonne direction comme qStudio
aujourd'hui transformé en Delphi for Php, un IDE qui permet de construire ses
formulaires visuellement rapidement. Cela reste néanmoins beaucoup plus
compliqué à mettre en route qu'un Access ou un Paradox et cela ne résoud pas le
problème important des états (Les techniciens purs ont tendance à laisser de
côté les états pourtant très importants pour l'utilisateur !).

Bon pour conclure j'essaie de noter dans un forum public tous les innovations
qui me semblent intéressantes de ce point de vue :
http://www.clairinfo.fr/phpBB2/viewforum.php?f
Encore une fois je ne prétends pas détenir de vérité, c'est un simple retour
d'expérience d'un ex "user" devenu développeur il y a maintenant 14 ans.

Côme
Mo2
Le #21872231
Côme de Christen a écrit :
Salut

"Mo2" 45f154e6$0$31988$
[...]
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, ?)?



MySql est un très bon compromis simplicité / stabilité / performance d'où son
succès logique.
Effectivement ce type de base nécessite un frontend pour un accès confortable.
Pour MySql le choix est tout de même vaste puisqu'il existe un pilote ODBC.
Concrètement tous les produits compatibles ODBC (Access, Paradox...) vont
pouvoir attaquer le serveur SQL en exploitant leurs atouts propres (facilité de
construction de formulaire, de requête, d'états).

J'ai écrit un article sur ce sujet :
http://www.clairinfo.fr/scripts/trace.php?noart (en anglais par contre
désolé) montrant une telle utlisation avec Paradox / MySql.

Sans prétendre que cela soit LA solution c'est une piste intéressante pour une
petite structure :

- choisir une base Sql de stockage (autant rester dans les classiques
connues fiables et ouvertes)
- choisir un front-end simple capable de construire fomulaire, état et
requêtes visuellement (la perle rare, je ne trouve pas malheureusement
l'équivalent de Paradox modernisé)
- utiliser les tableurs en bout de chaine pour des présentations libres et
les graphes

Ce dont il faut se méfier, je trouve, ce sont les conseils de techniciens purs
qui ne veulent pas comprendre le vrai souci légitime d'un utilisateur d'accéder
librement et facilement à toutes ses données. SQL (le langage) n'est pas la
panacée loin de là pour un utilisaeur. Si l'on sort de ce sentier sans
compétence informatique interne on est un peu condamné à utiliser des logiciels
standards ou à sous-traiter le développement et l'on retombe dans la perte
d'autonomie plus ou moins forte en fonction de la complexité de la base et du
frontend choisi.

L'évolution "appli web" que nous constatons a eu jusqu'ici plutôt tendance à
compliquer le développement qu'à le simplifier (mélange de langages et de
syntaxe notamment) Il faut espérer que cela change et que l'on puisse échapper
aux énormes framework usines à gaz à la mode actuellement. Puisque tu évoquais
Php (un langage au succès bien mérité là aussi de part sa simplicité d'accès) on
commence à percevoir des outils qui vont dans la bonne direction comme qStudio
aujourd'hui transformé en Delphi for Php, un IDE qui permet de construire ses
formulaires visuellement rapidement. Cela reste néanmoins beaucoup plus
compliqué à mettre en route qu'un Access ou un Paradox et cela ne résoud pas le
problème important des états (Les techniciens purs ont tendance à laisser de
côté les états pourtant très importants pour l'utilisateur !).

Bon pour conclure j'essaie de noter dans un forum public tous les innovations
qui me semblent intéressantes de ce point de vue :
http://www.clairinfo.fr/phpBB2/viewforum.php?f
Encore une fois je ne prétends pas détenir de vérité, c'est un simple retour
d'expérience d'un ex "user" devenu développeur il y a maintenant 14 ans.

Côme




En effet, je ne tiens pas à installer un énorme système complexe, qui
devra être maintenu par un professionnel. La taille de notre société ne
nous le permet pas vraiment, en plus de devoir imposer un changement des
outils et des habitudes aux autres (toujours problématique), même s'il
faut bien évoluer. Si je tiens à mon idée d'une base de données, même
externe comme MySql, avec utilisation dans un tableur classique, c'est
pour que ce soit simple à utiliser, et pas trop déroutant.
J'ai jeté un oeil à Crystal Reports. Ce genre d'outil semble
parfaitement réaliser ce que j'ai en tête, même si un peu complexe, sans
parler du prix de la licence (ouch). J'ai du coup regardé les solutions
open source, et il faut également un certain niveau de compétences. En
fait le problème principal que j'ai avec ces outils de rapports open
source est la connexion à la base de données (impossible de se
connecter, pilote odbc ou mysql absent, etc.). Je présume que ce genre
de problème est résolu dans les solutions commerciales.
Suite discussion ce matin avec le big boss, je fais un petit dossier
d'explications, de coûts, et d'exemples pour voir ce qu'il est possible
de faire, et s'il est convaincu, on met ça en place pour que tout soit
opérationnel l'année prochaine au 1er janvier au plus tard.
Ceci étant avec tout ce que vu sur internet (forums, etc.), le monde des
bases de données ressemble à la 4e dimension :)
Par ex. un internaute qui pose un problème simple (un peu comme moi), et
un administrateur de bdd qui résout le problème en une 50aine de
commandes sql complètement obscures (join imbriqués, etc.). Cela lui
semble simple mais bon, faut s'y connaître :)
Pour php, comme je disais dans un précédent post, je n'y connais rien,
on m'a fait quelques pages simples qui remplissent parfaitement leur
rôle pour entrer ou consulter des données brutes, mais ça s'arrête là.
Si on poursuit dans cette voie pour les formulaires/requêtes plus
complexes, ça va commencer à être sérieux et difficile à mettre en
oeuvre, sans compter qu'à chaque fois qu'on voudra faire une demande un
peu différente de ce qui est programmé, il faudra en fait programmer un
nouveau script php.
Bon ben j'ai pas fini du coup... :p
Merci à tous pour les renseignements.


Mo2
Publicité
Poster une réponse
Anonyme