[gull] Remplaçant de MS Access

[Cédric Rochat]

On Mer 26 avril 2006 9:59, Marc SCHAEFER a écrit :
> On Wed, Apr 26, 2006 at 08:33:41AM +0200, Julien Escario wrote:
>> J'ai exactement le même problème depuis pas mal de temps (environ 2
>> ans).
>
> Un ami a migré (et migre toujours) progressivement une entreprise de la
> manière suivante:
>
>    étape 1: passer la DB à PostgreSQL, garder MS Access
>    étape 2: réécrire la plupart des fonctions de base (impression des
>             factures, résumés comptables, etc) en Perl et PL/SQL en
> attaquant
>             directement la base, accédé via un formulaire WWW.
>    étape 3: migrer de plus en plus de fonctionnalités
>    étape 4: se débarrasser du client propriétaire
Dans l'entreprise pour laquelle je travaille, je fais des migrations
beaucoup plus délicates :
La structure de la base de données Access n'étant pas toujours optimale
(dans quelques cas, aucune intégrité référentielle, de la redondance
partout, au point de se demander si ça ne serait pas plus utilisable dans
un tableur), je refais la conception d'une nouvelle structure (je change
aussi les noms des tables et des champs, vu que dans Access, ils
comportent souvent des espaces, accents, caractères spéciaux, etc...) sur
PostgreSQL.
Ensuite, je crée une connexion ODBC sur PostgreSQL depuis Access, et dans
Access, je crée des requêtes d'exportation des données dans PostgreSQL.
Pour un cas en particulier, ce qui est très compliqué, c'est que la
migration ne peut pas se faire en une seule fois (la même base Access gère
plusieurs choses plus ou moins indépendantes l'une de l'autre, et la
migration d'une seule de ces choses à été planifiée pour le moment). Là où
le problème se complique très franchement, c'est que la partie que je
migre doit utiliser des données de la partie qui reste sur Access, et que
le client est susceptible de modifier quand il le souhaite... ce qui
implique de créer un système d'"import-export" des informations entre
Access et PostgreSQL afin de conserver une certaine intégrité entre deux
bases qui ne seront plus du tout les mêmes (ARGGGGGHHHH !!!).

Après cette étape extrêmement délicate, il y a la partie d'interface
utilisateur (Web) pour agir sur la base PostgreSQL.
Mais là, je me pose encore la question de la rapidité de création. Il faut
être efficace pour faire des formulaires, des états, etc... tout ça en
version Web ! Pour l'instant, je fais du PHP5 en orienté-objet à 100%,
afin d'avoir un "retour sur investissement" dans les prochaines
applications du genre.
Mais j'avoue que je songe très sérieusement à passer sur RubyOnRails !!
Là, il faudrait estimer le temps d'adaptation à ce language, mais je pense
que ce serait une bonne solution à terme...

RubyOnRails vs Django vs ??? Je vais m'attirer les foudres de certains si
je dis que Perl à fait son temps, d'autant plus que je ne suis pas
suffisamment expérimenté en Perl pour porter un jugement... je crois
surtout que c'est une question de goût !
Mais ça, c'est une autre histoire, et un autre débat :-)

En tout cas, au niveau des problèmes rencontrés avec Access quand on doit
reprendre le travail de quelqu'un d'autre pour corriger des bugs ou
ajouter des fonctionnalités... c'est loin d'être rentable, et il y a de
quoi écrire une bibliothèque complète au sujet des prises de tête...
Pour moi, c'est clair :
Access en tant que SGBD n'a pas sa place dans un milieu professionnel !
Mais  à la limite, pourquoi ne pas le garder comme simple interface
utilisateur, dans certains cas où les clients ne veulent pas investir dans
un nouveau développement ?

-- 

********************************
         Cédric Rochat
********************************
Rue des Fleurs 34
CH-2300 La Chaux-de-Fonds
priv: crochat at younics.org
     crochat at phpmydvds.org
********************************
prof: cedric.rochat at he-arc.ch
      crochat at jmburri.ch
********************************
homepage: http://www.younics.org
          http://www.phpmydvds.org
          http://www.jmburri.ch
********************************