- 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.
- 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.
- 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.
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.
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.
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.
J'ai également fait un test avec MySQL
J'ai également fait un test avec MySQL
J'ai également fait un test avec MySQL
Mo2 wrote:J'ai également fait un test avec MySQL
Ne pas oublié PostGreSQL si tu as encore le temps.
Mo2 wrote:
J'ai également fait un test avec MySQL
Ne pas oublié PostGreSQL si tu as encore le temps.
Mo2 wrote:J'ai également fait un test avec MySQL
Ne pas oublié PostGreSQL si tu as encore le temps.
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.
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.
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 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... ;-)
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... ;-)
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... ;-)
"Mihamina (R12y) Rakotomandimby" a écrit dans
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.
"Mihamina (R12y) Rakotomandimby" <infogerance@asso-polyvalente.fr> a écrit dans
le message de news: espedq$2v2o$1@cabale.usenet-fr.net...
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.
"Mihamina (R12y) Rakotomandimby" a écrit dans
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.
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
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
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
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, ?)?
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, ?)?
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, ?)?
Salut
"Mo2" a écrit dans le message de news:
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
Salut
"Mo2" <bouchon.mo2@free.fr> a écrit dans le message de news:
45f154e6$0$31988$426a34cc@news.free.fr...
[...]
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
Salut
"Mo2" a écrit dans le message de news:
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