Comparatif SGBD (in Cahiers du Programmeur Mac OS X)

payman <payman@libertysurf.fr> wrote:

Plus simple, non !!!
Deja si tu trouve un SGBD en open source (GPL) portable Mac/PC/unix
en dehors de Postgresql/Mysql c'est miracle :)

il y a Hpersonic SQL <http://hsqldb.sourceforge.net/> 100% java, la
lincense a l'air très souple, qui peut-être embarauée dans
l'application, pour de "petites" db.
--
yt

Christophe Franco <cfranco@pobox.com> wrote:

payman <payman@libertysurf.fr> wrote:

cfranco@pobox.com (Christophe Franco) wrote in message
news:<1gdeuoy.mfrefg1ojfxfkN%cfranco@pobox.com>...

payman <payman@libertysurf.fr> wrote:

cfranco@pobox.com (Christophe Franco) wrote in message
news:<1gde6he.wc3uto1x8a2bwN%cfranco@pobox.com>...

payman <payman@libertysurf.fr> wrote:

Effectivement modifier schema avec oracle est galere avec 8i fallait
creer une autre table et migrer les donnees mais sur 9i un peut plus
simple mais bon (j'ai pas eu le temps de voir 10g encore)!! C'est
aussi le cas sur Postgresql !

Et connais-tu des SGBD pour lesquels cela peut être plus simple ? Je
suis ouvert à tout, pouvu que ça soit utilisable avec Java (via JDBC, ce
qui laisse la porte ouverte à pas mal de choses), et de préférence avec
une licence libre qui ne soit pas GPL.

Plus simple, non !!!
Deja si tu trouve un SGBD en open source (GPL) portable Mac/PC/unix
en dehors de Postgresql/Mysql c'est miracle :)

Mauvais exemple déjà, parce que PostgreSQL c'est du BSD, et MySQL c'est
du GPL seulement quand ça veut bien...

Mais plus ça va, et plus je pense que je vais me tourner vers
PostgreSQL, c'était mon idée de départ, mais j'avoue que j'étais un peu
freiné par l'absence de version native Windows. Là j'ai vu qu'en fait il
a l'air compilable sous Windows, des gens l'ont fait, ça devrait aller.
En plus, j'ai mis la main sur des infos sur PostGIS, qui devrait être
d'un grand intérêt pour mon projet...

merci à tous !
Oulaaa Oui, mais bon moi ce qui m'interesse c'est que postgresql est

gratos et opensource (gratos = pas de licence developpeur pas de
royaltee etc ...) d'ou le melange :)

tien un article qui pourrait t'interesser : (ptit Comparatif SGBD
SqlServeur,
MySQL, Postgresql)

http://www.mairies-online.fr/demo/article.php?id_article…4

et pour version windows :
http://techer.pascal.free.fr/postgis/psqlwin/#x1-30000.1.1
et puis le grand maitre de postgresql (momjian)
http://momjian.postgresql.org/main/writings/pgsql/win32.html

voila
Bon courage
A+
Payman

Christophe Franco <cfranco@pobox.com> wrote:

J'ai bossé suffisamment longtemps à refaire dans des langages sérieux
des cochonneries bâclées sous 4D pour le savoir...

le problème est bien là : elles avaient été baclée ; mais correctement
faites avec une analyse préalable bien foutue, elles auraient mieux
fonctionné qu'avec un cimetière de donnée genre Oracle ou Acces. Au lieu
de faire ça, on appelle un grand informaticien, qui fort de sa merise
balaie tout et passe sous SQL.
Résultat très habituel : quand on a besoin d'une nouvelle requete, on
quémande une réunion du groupe utilisateur qui transmettra une demande
de modification au développeur, et 2 ans après on aura un dialogue qui
ne respondra pas à la question mais permettra au developpeur de cocher
la case : DI satisfaite. Il aura remplit son objectif annuel.
La base ne fais plus chier personne, et devient inutile. Du coup, les
utilisateurs font des extractions et se refont à coté une autre base.
Mouaaaarffff. Vu des 10aines de fois dans plusieurs endroits.

En tout cas, parler de langage sérieux pour SQL, c'est se moquer du
monde ; ça fait 20 ans que je supporte des cochoncetés sous SQL et
apparentés, qui rendent très heureux les informaticiens mais qui ne
servent à rien...

c'est un peu ça le problème des SGDB : difficile de satisfaire à la fois
le fabricant et l'utilisateur. Mais faut-il faire des bases pour
l'utilisateur, ou pour le codeur ?
--
Philippe Manet
pmanet@invivo.edu

manet <pmanet@invivo.edu> wrote:

Christophe Franco <cfranco@pobox.com> wrote:

J'ai bossé suffisamment longtemps à refaire dans des langages sérieux
des cochonneries bâclées sous 4D pour le savoir...

le problème est bien là : elles avaient été baclée ; mais correctement
faites avec une analyse préalable bien foutue, elles auraient mieux
fonctionné qu'avec un cimetière de donnée genre Oracle ou Acces. Au lieu
de faire ça, on appelle un grand informaticien, qui fort de sa merise
balaie tout et passe sous SQL.
Résultat très habituel : quand on a besoin d'une nouvelle requete, on
quémande une réunion du groupe utilisateur qui transmettra une demande
de modification au développeur, et 2 ans après on aura un dialogue qui
ne respondra pas à la question mais permettra au developpeur de cocher
la case : DI satisfaite. Il aura remplit son objectif annuel.

Et bien vois-tu, c'est exactement le contraire de ce que j'ai vécu :
passer de bases développées sous 4D ou autres, à des bases sous Oracle
ou autre mais avec une partie programmation dans des langages du genre
Java, ça a pour objectif entre autres de justement faciliter les
évolutions futures.

Parce qu'avec un truc développé sous 4D, ce qui se passe généralement,
c'est que d'une part il est très difficile de trouver un programmeur qui
connaîsse le langage (alors que Java ou C++ ça court les rues), et
ensuite quand on en trouve un il constate assez vite que le code
existant n'a de sens compréhensible que dans la tête de celui qui l'a
écrit, qu'il faut donc aller le rechercher pour qu'il daigne pondre - à
prix d'or généralement, il est en position de force - une évolution de
son vieux boulot.

Au contraire, avec une structure ouverte, des langages plus répandus,
une structure au strict minimum à 3 couches (plus si possible), on a
nettement plus de possibilités de pouvoir intervenir un jour ou l'autre
pour corriger un bug ou ajouter des fonctionnalités. C'est aujourd'hui
une demande extrèmement intransigente de beaucoup de clients (pour ne
pas dire tous) que de n'utiliser que des langages et des logiciels
suffisamment ouverts et connus pour pouvoir ne pas se retrouver
dépandant du travail du prestataire ou de l'éditeur de logiciels.

Pour en finir avec 4D, le pire que j'ai rencontré, c'est un projet où le
moteur de base de données de 4D avait été jugé tellement mauvais que le
programmeur avait pris le parti de reprogrammer une gestion de base de
données à partir de zéro dans le langage de 4D (qui a dit NIH ?)... Mais
c'était un cas un peu tordu, où le client avait demandé 4D à l'époque
parce que c'est un produit français...

--
Christophe Franco

Christophe Franco <cfranco@pobox.com> wrote:

C'est aujourd'hui
une demande extrèmement intransigente de beaucoup de clients (pour ne
pas dire tous)

ah mais je le sais bien !!! je suis en plein dedans !!!

maintenant, on ne demande plus leur avis aux utilisateurs, on fait
rédiger les cahiers des charges par des informaticiens (tu appelle ça
des clients, moi je dis plutot des complices...) !!! alors évidemment,
il n'y a plus que du Oracle partout ! quand on n'y ajoute pas du Tuxedo
pour avoir un beau moniteur transactionnel que personne ne sait faire
fonctionner. .. mais c'est terriblement performant !

et on arrive à ce que je te dis :

des bases qui fonctionnent très bien, mais personne n'a jamais pensé
qu'elles étaient là pour y faire des requetes, et rien n'est prevu pour.
D'ailleurs, les grands spécialistes de la programmation de ce genre de
base sont bien obligés d'avouer qu'on ne peut rien en faire. Il faut
commencer par en tirer le jus dans des info centres (le problème, c'est
qu'on en sait jamais quoi y mettre), puis les attaquer avec des univers
BO ou autres. Et hop, on recasque quelques dizaines de milliers d'euros
pour avoir BO... et évidemment, là non plus, personne ne sait s'en
servir, il faut appeler des consultants à 2000 euros la journée, etc...
MDR

Alors elles ronronnent tranquillement sur leur bo serveur trois tiers,
miam miam, tout le monde est content, on est revenu aux années 70.

Et les utilisateurs bossent sur Excel. Pour l'instant, on leur laisse,
parce que la direction croit que ça sert à faire des tableaux de
service.
--
Philippe Manet
pmanet@invivo.edu

manet <pmanet@invivo.edu> wrote:

Christophe Franco <cfranco@pobox.com> wrote:

C'est aujourd'hui
une demande extrèmement intransigente de beaucoup de clients (pour ne
pas dire tous)

ah mais je le sais bien !!! je suis en plein dedans !!!

maintenant, on ne demande plus leur avis aux utilisateurs, on fait
rédiger les cahiers des charges par des informaticiens (tu appelle ça
des clients, moi je dis plutot des complices...) !!! alors évidemment,
il n'y a plus que du Oracle partout ! quand on n'y ajoute pas du Tuxedo
pour avoir un beau moniteur transactionnel que personne ne sait faire
fonctionner. .. mais c'est terriblement performant !

Le problème est un petit peu plus complexe que ça quand même, quand on
bosse avec des grands comptes, on a généralement en face de soi un ou
plusieurs chefs de projet, généralement des profils techniques mais pas
informaticiens. Ils font bel et bien un cahier des charges fonctionnel,
correspondant aux besoins de l'entreprise cliente. Mais ils ne sont
souvent pas non plus les utilisateurs du futur logiciel, dont
l'exploitation sera confiée à des gens moins élevés hiérarchiquement.
(qu'on ne voit pas souvent, ne serait-ce que parce que dans de longs
projets de développement, s'étalant sur des mois voire des années, il
n'est pas rare qu'ils ne soient pas encore en poste au moment où le
cahier des charge est rédigé)

A côté de ça, les services informatiques (et de plus en plus les
services juridiques) ajoutent des conditions de plus en plus fermes sur
la technique, afin d'éviter de se retrouver pieds et poings liés dans le
système vendu. Mais je n'en ai jamais vu qui te disent "je veux Oracle
et Tuxedo", plutôt ils attendent d'avoir ton étude détaillée avec tous
les langages et les logiciels utilisés, pour valider - ou pas - par
rapport à leurs références. Et au contraire, il est quasiment impossible
d'obtenir a priori cette référence. Mais tu as d'autant plus raison de
parler de "complices", parce que de plus en plus ces gens-là sont
eux-mêmes employés de SSII (parfois même les mêmes SSII que celles qui
font le boulot), miracle de l'externalisation.

Il est clair que le grand absent de tout ça, c'est l'utilisateur final.
Mais il n'empèche que ce n'est pas une excuse pour livrer un logiciel
qui ne marche pas, c'est au prestataire ou à l'éditeur de logiciels de
faire ce qu'il faut pour livrer un logiciel utilisable par un
non-informaticien, et à - si je peux me permettre - tirer les vers du
nez de ses interlocuteurs pour connaître au mieux le profil de cet
utilisateur, s'il ne peut y avoir accès directement.

Là où ça devient plus génant, c'est quand tu as des boites où lorsqu'il
y a une formation à la livraison du logiciel, tu as tous les chefs de
service qui y assistent, mais pas un seul utilisateur final. Raison ?
Les utilisateurs finaux sont bien souvent des stagiaires ou des jeunes
embauchés en CDD, ils ne restent pas assez longtemps en poste pour
justifier de les envoyer en formation... Ou même ils n'ont pas encore
été embauchés, avec les retards caractéristiques des projets
informatiques ils attendent que le logiciel soit livré et fini d'être
débuggé pour embaucher les utilisateurs. Et après, on récupère tout ça
en hotline...

--
Christophe Franco

Christophe Franco <cfranco@pobox.com> wrote:

Mais tu as d'autant plus raison de
parler de "complices", parce que de plus en plus ces gens-là sont
eux-mêmes employés de SSII (parfois même les mêmes SSII que celles qui
font le boulot)

aurais-tu eu affaire à cap Gemini ?

pour revenir au débat, je crois que le principal endroit où tu as
raison, c'est quand tu dis qu'on a du mal à trouver des gens qui
connaissent bien 4D, alors qu'on en trouve plein qui connaissent PHP et
MySQL. Il y a un gros problème d'enseignement dans les écoles d'info.

mais j'insiste, revenir aux bases Oracle et Cie, c'est une formidable
régression.
On avait eu un débat de ce genre sur le forum FMP ; un gars disait :
grace aux grosses bases DB2, vous avez votre solde bancaire en une
fraction de seconde dans n'importe lequel des X0000 DAB de france et de
navarre, ce qui est impossible avec FMP.

J'ai bien du concéder que c'était véridique (encore que je pense qu'un
4D bien foutu avec des données bien réparties devrait s'en tirer
honorablement). Mais je lui ai expliqué qu'obtenir mon solde était une
opération bien misérable ; ce que j'aimerais, c'est pouvoir obtenir de
ma banque la moyenne des CB que j'ai faite à carrefour et auchan en juin
juillet, en excluant les sorties > 1000 euros et en faire le listing
trié par jour de la semaine.. Et ce genre de prestation générique, tu
peux t'aligner avant de le fournir avec DB2 ou Oracle. Ces SGDB, je les
appelle des cimetieres de données ; on rentre plein de truc ddedans,
qu'on en pourra jamais exploiter.
Toutes les méthodes que tu explique partent d'un prémice faux : on
saurait d'avance (et on va donc pouvoir organiser) ce qu'on veut obtenir
de la base. C'est une aberration démentie tous les jours par la réalité
: chaque résultat d'exploitation pose des questions qui nécessite une
nouvelle exploitation.

Quand à SQL, il est disqualifié d'emblée : il mélange à chaque requete
la selection des enregistrement, le tri des données et le choix des
champs à présenter. C'est d'un crétinisme total ; je ne comprend pas
qu'on en soit encore là, alors que les SGDB permettant de séparer les 3
fonctions existent depuis 20 ans.

Et ne parlons pas de la nécessité d'avoir des DBA dont la tache
épanouissante consiste à surveiller jour après jour la bonne santé des
index et des segments. On croit réver ; et dire que ce sont des
informaticiens ! petit, je m'imaginais que le role de l'ordinateur était
de prendre en charge les boulots répétitifs et débiles. Ben dis donc !

Finalement, le fait d'utiliser partout des outils différents (les fameux
3 tiers) entraine une certitude : on n'a jamais les bonnes versions en
meme temps à tous les niveaux. Maintenance horriblement couteuse, patchs
dans tous les sens à tous moments, bordelisation assurée. L'unicité de
4D et FMP est un gage de cohérence du système.

A mon sens, le monde des bases de données à 20 ans de retard sur le
reste de l'informatique. Et c'est bien parce que là plus qu'ailleurs,
les informaticiens ont très vite repris le pouvoir sur les utilisateurs.
Et ça continue, avec Terminal Serveur et TCPA, on va bientot nous
arranger tout ça !

Heureusement, Filemaker reste le SGDB le plus vendu aux US ; il reste
là-bas suffisament de gens pragmatiques et sachant compter. Mais c'est
ahurissant : en France, personne ne connait, on ne trouve quasiment
aucun professionnel capable de proposer des solutions FMP. Alors qu'ils
utilisent intensivement Access, qui sauf quelques rares situations lui
est bien inférieur.

Et donc, pour tes problèmes, FMP probablemnet, ou 4D si shema de donnée
vraiment tordu, restent d'excellents choix, probablement les meilleurs.
Je ne pense pas qu'il existe des problèmatiques mono utilisateurs (meme
si on en arrive dans certains cas à des dizaines de postes, ton problème
est susceptible d'etre mono-utilisateur, donc pas très complexe) qui
nécessitent autre chose. Dans une petite structure, on connait bien ses
données et on aimerais les exploiter à fond, et c'est vraiment là que
les bases SQL sont de loin les plus nocives.
MySQL et ses copains, excuse moi, mais c'est du snobisme de technicien
qui se la joue. Si tu pense à tes clients, FMP.

--
Philippe Manet
pmanet@invivo.edu

pour revenir au débat, je crois que le principal endroit où tu as
raison, c'est quand tu dis qu'on a du mal à trouver des gens qui
connaissent bien 4D, alors qu'on en trouve plein qui connaissent PHP et
MySQL. Il y a un gros problème d'enseignement dans les écoles d'info.

Ah bon ? Je vois pas le rapport entre l'enseignement dans les cursus
Informatique et le fait qu'il soit dur de trouver des "développeur"
sur un truc propriétaire.



Hub
--
GPG fingerprint: 6C44 DB3E 0BF3 EAF5 B433 239A 5FEE 05E6 A56E 15A3

manet <pmanet@invivo.edu> wrote:

Christophe Franco <cfranco@pobox.com> wrote:

pour revenir au débat, je crois que le principal endroit où tu as
raison, c'est quand tu dis qu'on a du mal à trouver des gens qui
connaissent bien 4D, alors qu'on en trouve plein qui connaissent PHP et
MySQL. Il y a un gros problème d'enseignement dans les écoles d'info.

Euh, non, là je ne crois pas du tout... Au contraire, si les écoles
d'info peuvent enseigner plutôt des langages ouverts et non
propriétaires, plutôt que des trucs comme 4D, ça ne sera que mieux. Cela
dit, PHP/MySQL n'est pas le meilleur exemple, loin de là.

Par contre, j'ai connu pas mal de SSII qui ne font que du 4D (ou du
WinDev) et le refouguent à toutes les sauces, parce qu'elles ne
connaîssent que ça. Mais effectivement, en général elles ne le
connaîssent même pas bien...

mais j'insiste, revenir aux bases Oracle et Cie, c'est une formidable
régression.
On avait eu un débat de ce genre sur le forum FMP ; un gars disait :
grace aux grosses bases DB2, vous avez votre solde bancaire en une
fraction de seconde dans n'importe lequel des X0000 DAB de france et de
navarre, ce qui est impossible avec FMP.

J'ai bien du concéder que c'était véridique (encore que je pense qu'un
4D bien foutu avec des données bien réparties devrait s'en tirer
honorablement). Mais je lui ai expliqué qu'obtenir mon solde était une
opération bien misérable ; ce que j'aimerais, c'est pouvoir obtenir de
ma banque la moyenne des CB que j'ai faite à carrefour et auchan en juin
juillet, en excluant les sorties > 1000 euros et en faire le listing
trié par jour de la semaine.. Et ce genre de prestation générique, tu
peux t'aligner avant de le fournir avec DB2 ou Oracle. Ces SGDB, je les
appelle des cimetieres de données ; on rentre plein de truc ddedans,
qu'on en pourra jamais exploiter.

Ca, c'est pas un problème de SGBD, c'est un problème des couches
supérieures. Tu mélanges tout parce qu'avec 4D ou FMP (ou autres, WinDev
par exemple) tu as ensemble la base de donnée, et un front-end
préprogrammé, et c'est précisément leur problème. Rien n'empèche de
développer de quoi proposer à l'utilisateur de faire très simplement ses
propres requêtes. Dans le dernier projet où j'ai travaillé, c'était
fait, et c'était sur une base Oracle ! Et ça marche... Mais c'est du
boulot, et c'est certain que tu as moins de choses déjà toutes faites
sur un système ouvert (encore que, les composants réutilisables pour tel
ou tel langage ça existe) que pour un truc clé en main comme FMP ou 4D.

Maintenant, tout le monde (tous les éditeurs de logiciels je parle) n'a
pas la volonté de laisser les utilisateurs faire leurs propres requêtes
sur la base... Parce que ça veut dire qu'ils ne sont plus prisonniers de
cette base précisément, qu'ils peuvent donc se passer des services de
ceux qui l'ont vendue... Et tous les clients ne mesurent pas forcément
l'importance de cela.

Toutes les méthodes que tu explique partent d'un prémice faux : on
saurait d'avance (et on va donc pouvoir organiser) ce qu'on veut obtenir
de la base. C'est une aberration démentie tous les jours par la réalité
: chaque résultat d'exploitation pose des questions qui nécessite une
nouvelle exploitation.

Quand à SQL, il est disqualifié d'emblée : il mélange à chaque requete
la selection des enregistrement, le tri des données et le choix des
champs à présenter. C'est d'un crétinisme total ; je ne comprend pas
qu'on en soit encore là, alors que les SGDB permettant de séparer les 3
fonctions existent depuis 20 ans.

Là encore, c'est pas parce qu'il peut faire le tout en même temps que
c'est ce qu'il faut faire... On n'est pas obligé de tout coder sous
forme de base de données, il est également possible de limiter la base
de données... aux données, et d'utiliser une ou plusieurs des couches
supérieures pour coder le reste. C'est d'ailleurs là qu'est LE grand
intérêt de ne pas utiliser des front-ends de base de données, mais de
faire un vrai développement avec des vrais langages et une vraie
structure. A court terme, c'est sûr que ça prend un peu plus de temps,
mais ça vieillit nettement mieux...
`

Et ne parlons pas de la nécessité d'avoir des DBA dont la tache
épanouissante consiste à surveiller jour après jour la bonne santé des
index et des segments. On croit réver ; et dire que ce sont des
informaticiens ! petit, je m'imaginais que le role de l'ordinateur était
de prendre en charge les boulots répétitifs et débiles. Ben dis donc !

Finalement, le fait d'utiliser partout des outils différents (les fameux
3 tiers) entraine une certitude : on n'a jamais les bonnes versions en
meme temps à tous les niveaux. Maintenance horriblement couteuse, patchs
dans tous les sens à tous moments, bordelisation assurée. L'unicité de
4D et FMP est un gage de cohérence du système.

Je crains que tu n'aies pas compris ce que signifie 3 tiers... Remarque,
t'es pas le seul, j'en ai déjà vu qui ont sorti comme argument "mais si,
on fait du 3 tiers, la preuve c'est qu'on utilise un navigateur web !"

Cela dit, une architecture 3 tiers me semble déjà bien limitée, guère
plus qu'un palliatif à des structures monolithiques ingérables destiné à
ne pas trop choquer les gens habitués à faire ce genre de choses. Si on
veut quelque chose de sérieux, j'ai du mal à voir comment faire
en-dessous de 5 couches... ce qui ne veut pas forcément dire 5 outils
différents pour le faire...

A mon sens, le monde des bases de données à 20 ans de retard sur le
reste de l'informatique. Et c'est bien parce que là plus qu'ailleurs,
les informaticiens ont très vite repris le pouvoir sur les utilisateurs.
Et ça continue, avec Terminal Serveur et TCPA, on va bientot nous
arranger tout ça !

Heureusement, Filemaker reste le SGDB le plus vendu aux US ; il reste
là-bas suffisament de gens pragmatiques et sachant compter. Mais c'est
ahurissant : en France, personne ne connait, on ne trouve quasiment
aucun professionnel capable de proposer des solutions FMP. Alors qu'ils
utilisent intensivement Access, qui sauf quelques rares situations lui
est bien inférieur.

Les raisons ne manquent pas pourtant... Access tu l'as quasiment
gratuitement quand tu prends des licences groupées avec le reste
d'Office dont tu as besoin aussi, et puis Access contrairement à FMP et
4D n'a pas la "tare" d'avoir l'image d'être un logiciel provenant du
monde Mac...

Ajoute à cela qu'Access "ressemble" assez à Excel, tu as tout ce qu'il
faut pour que les gens qui sont habitués à l'un ne soient pas trop
effrayés par l'autre. (encore qu'avec des produits de tierce partie, on
puisse faire à peu près la même chose avec Oracle ou PostgreSQL par
exemple)

Cela dit, pour des petits trucs faits sous Access, il est clair que l'on
gagne en général à les faire sous FMP. Mais on ne parle pas du même type
de développement là...

Et donc, pour tes problèmes, FMP probablemnet, ou 4D si shema de donnée
vraiment tordu, restent d'excellents choix, probablement les meilleurs.
Je ne pense pas qu'il existe des problèmatiques mono utilisateurs (meme
si on en arrive dans certains cas à des dizaines de postes, ton problème
est susceptible d'etre mono-utilisateur, donc pas très complexe) qui
nécessitent autre chose. Dans une petite structure, on connait bien ses
données et on aimerais les exploiter à fond, et c'est vraiment là que
les bases SQL sont de loin les plus nocives.

Mouarf la "petite structure"... Je ne crois pas avoir un client qui ait
moins de 100 000 employés...

MySQL et ses copains, excuse moi, mais c'est du snobisme de technicien
qui se la joue. Si tu pense à tes clients, FMP.

Non, FMP ou 4D, c'est là qu'est le vrai piège, parce que une fois le
développement fait et bien vérouillé dans le système, comment va-t-il
évoluer ? Qui gardera les compétences pour intervenir dessus ? Comment
peut-on s'assurer de son bon fonctionnement ? Beaucoup de clients l'ont
compris, c'est déjà bien, l'ennui c'est peut-être qu'ils n'aient pas
compris qu'Access c'est du même topo, même s'il y a plus de gens qui le
connaissent.

Et puis même pour le développement, c'est bien plus difficile à
programmer qu'avec un langage comme Java par exemple, du fait d'un
manque de rigueur considérable dans le langage, techniquement c'est en
fait beaucoup plus dur si on veut faire quelque chose de propre.
L'ennui, c'est que bien peu de gens se soucient de faire quelque chose
de propre, et à court terme on n'en mesure pas forcément les
conséquences...

Ton argumentaire me fait beaucoup penser à celui des gens qui font
toujours leur Fortran 77 "dans leur coin", en se disant "j'ai pas besoin
de plus complexe, c'est juste pour moi". Et puis, un peu plus tard, on
se dit que le type a de bonnes idées, et que ce qu'il a programmé ça
marche pas mal, et qu'on voudrait bien pouvoir l'exploiter à plus grande
échelle. Là, deux solutions :
- tout réécrire à partir de zéro : pas toujours facile à justifier quand
tu as quelqu'un en face qui dit "mais si regardez, ça marche très bien
mon truc, ça sert à rien de le jeter", et puis l'ego du gars qui l'a
fait à l'origine en prend un sacré coup ;
- faire une sur-couche comme on peut pour "enrober" le programme avec
une inteface plus conviviale, et là on finit généralement avec un truc
incompréhensible, où la logique du gars aura été reproduite de manière
plus ou moins heureuse, et ça aura couté cher...

Je crois qu'on ne peut pas tout mélanger... C'est comme à l'école, on
m'a appris une chose, c'est qu'il y a le brouillon et il y a la copie
qu'on rend. Le brouillon c'est le brouillon, la copie c'est la copie. Si
la copie ressemble à un brouillon, c'est pas bon, mais si le brouillon
est aussi propre et bien rédigé que la copie, c'est pas non plus ce
qu'il faut faire...

--
Christophe Franco

Christophe Franco <cfranco@pobox.com> wrote:

Par contre, j'ai connu pas mal de SSII qui ne font que du 4D (ou du
WinDev) et le refouguent à toutes les sauces, parce qu'elles ne
connaîssent que ça. Mais effectivement, en général elles ne le
connaîssent même pas bien...

exact ! souvent, elles ne comportent pas de véritable informaicien ayant
un background

--
Philippe Manet
pmanet@invivo.edu