Arguments pour et contre Access ?

[bottura]

je cherche une synthèse des arguments permettant de convaincre un décideur d'abandonner Access pour un vrai SGBD.
Merci d'avance.


[EDIT par FRED.G] A tous ceux qui s'apprêtent à entrer dans le débat je recommande vivement la lecture de cet excellent article de Papy Turbo : Développement professionnel avec Access : Pourquoi quelqu'un qui gagne sa vie en écrivant des logiciels sur mesure irait choisir Access comme principal outil de développement ? [/EDIT]

[Florian]

Access n'est pas Client/Serveur (pour le format de fichier access lui meme).
Access ne supporte pas les procédures stockées.
Access ne peut pas être accédé via ODBC ailleurs que sur le serveur où il est stocké.
Access ne gère pas les accès par utilisateurs (puisque ce n'est que du partage de fichiers).

Entre autres, mais tu va avoir beaucoup de réponses...

[bidou]

Access est mal sécurisé.
Access utilise un mode de verrouillage inadapté.

[UbiK]

- ne gere pas plus de 2Go de données
- l'allocation des ressources n'est pas paramétrable
- n'est pas, à proprement parler, un vrai SGBDR (pas un serveur de BDD en tout cas)
- moteur SQL poussif (comprendre pas tres rapide)
...etc ....

[laffreuxthomas]

Access ne peut pas être accédé via ODBC ailleurs que sur le serveur où il est stocké

je mettrai plutôt "ailleurs que sur l'intranet où il est stocké"

et sinon :

- Access plante rarement mais quand ça arrive toutes les données sont perdues.

Au niveau de la partie GUI (formulaires + états) :
- Aucune ouverture vers d'autres platformes de développement
- Le langage (VBA) n'est pas un langage professionnel:
- -> aucune possibilité de faire de l'objet
- -> le code grossit n'importe comment, il y en a vite partout et c'est impossible à maintenir.
- -> les modules de "génération automatique" de formulaires donnent souvent une mauvaise direction au développeur. (ce dernier point est un avis personnel)

Thomas

[SQLpro]

C'est un des plus mauvais SGBD qui a été créé !!!!

A lire : http://sqlpro.developpez.com/SQL_AZ_C.html

Pour comprendre la différence, voici un exemple simple. Une table de nom CLIENT contient 50 000 enregistrements de 200 octets chacun. La
requête est la suivante :

SELECT * FROM CLIENT WHERE (CLI_NAME like ‘%CLINTON%’)


Dans un SGBD de type fichier, voici le flot de données :

Le PC rapatrie depuis le serveur le fichier contenant la table CLIENT
Soit au minimum 50 000 x 200 octets (sans compter les index et le reste[1])
Le PC traite localement la requête
Le PC affiche le résultat
Soit par exemple 5 lignes de 200 octets


Dans un SGBD de type C/S, voici le flot de données :

Le PC envoi au serveur le fichier texte de la requête
Soit environ 50 octets
Le serveur exécute la requête sur la table CLIENT
Le serveur renvoi au PC les données répondant à la requête,
Soit nos 5 lignes de 200 octets
Le PC affiche le résultat


Bilan de ces opérations :
SGBD fichier : environ 10 001 000 octets ont été véhiculé sur le réseau
SGBD C/S : environ 1 050 octets ont été véhiculés sur le réseau

[1] le reste dépend de comment est constituée la base de données. Dans des SGBD de type fichiers intelligemment pensés, comme Paradox, le découpage de la base en
de multiples petits fichiers (données - .DB, mémo - .MB, clef - .PX, index secondaires - .Xnn/.Ynn) minimise le trafic réseau. Ce n’est pas le cas de SGBD mal pensés
comme Access qui ne comporte en tout et pour tout qu’un seul monstrueux fichier par base de donnée et par conséquent nécessite de véhiculer la totalité du fichier sur le
réseau pour chaque requête sur chaque poste client…


A +

[Maître Kenobi]

Bonjour,
pour SQLPRO, j'aimerais savoir dans le cas d'access s'il fonctionne de la meme maniere si par exemple je developpe cote client en delphi ou VB6 ( interfaces )et dans ce cas access sert uniquement au stockage des donnees
merci

[Etienne Bar]

En ouvrant un sujet pareil, tu pouvais être sur d'avoir une tonne de réponses ;-).

Ceci dit, il faut faire deux distinctions :

- Access en tant que moteur SQL que tu vas attaquer avec un outil de développement quelconque (Delphi ou autre). Je ne jugerais pas cet aspect (ne l'ayant pas testé) et je te laisse lire les autres témoignages qui sont sans doute vrais

- Access en tant que SGBD et outil de développement intégré. Au risque de faire pleuvoir sur ma pauvre tête plein de post injurieux, j'aimerais que tous ceux qui ici me donnent leur avis sur ce qui suit :

1) Dans une PME ou un groupe de travail d'une grande organisation, pour une application avec des volumes restreints (quelques dizaines de milliers de lignes -j'ai vu plus-) et un nombre d'utilisateurs raisonnables (je dirais moins de 10 et j'ai la aussi vu plus), quel outil vous permet de développer une application aussi vite qu'Access ? Je crée une table (avec une interface assez conviviale) et paf je crée un formulaire dessus en un clic de souris.
J'ai le sentiment que vous tous ici, chers collègues developpeurs, ne travaillez que sur des projets qui représentent plusieurs mois/hommes au minimum. On ne vous demande jamais de créer une application 'quick and dirty' en quelques jours, sur laquelle vos utilisateurs pourront éventuellement intervenir ?

2) Concernant les propos de Thomas :

Envoyé par laffreuxthomas

Au niveau de la partie GUI (formulaires + états) :
- Aucune ouverture vers d'autres platformes de développement

C'est vrai que tu ne peux pas mixer du code VBA avec autre chose, mais tu peux appeler des API et gérer des objets COM. Que veux tu de plus ?

Envoyé par laffreuxthomas

- Le langage (VBA) n'est pas un langage professionnel:
- -> aucune possibilité de faire de l'objet

Access ne gère l'héritage et l'encapsulation mais tu peux créer un objet et lui affecter des propriétés et des méthodes.

<provoc>
C'est quoi, un langage professionnel ? Quelque chose qui t'oblige à tout faire à la main ?
</provoc>

Envoyé par laffreuxthomas

- -> le code grossit n'importe comment, il y en a vite partout et c'est impossible à maintenir.

Bien sur, si tu programmes n'importe comment. Si tu te donnes des règles strictes, ton code sera relativement propre. Tu as des outils qui te permettent de créer des références croisées. Tu peux aussi faire du code immonde avec Delphi. La qualité, c'est autant une question de développeur que d'outil !

Envoyé par laffreuxthomas

- -> les modules de "génération automatique" de formulaires donnent souvent une mauvaise direction au développeur. (ce dernier point est un avis personnel)

C'est un avis qui t'est personnel, je répondrais qu'ils ont le mérite d'exister et qu'ils constituent un gain de temps non négligeable.

(heu, vous le prenez pas mal, les gars, hein ? On discute ! )

Et pour ne pas oublier le sujet du forum (arguments contre Access), si tu veux des arguments contre Access, en voilà quelques uns (toujours dans le domaine d'Access utilisé comme outil de dev. + SGBD)

1) Passer d'une version à une autre t'oblige parfois à modifier ton code.
2) ll faut installer Access sur chaque poste de travail (ou un Runtime qui pose souvent problème)
3) C'est une techno Microsoft et donc sa perennité est soumise à question (cf VB)
4) VBA est un langage qui autorise les pires acrobaties (il est possible d'omettre les déclarations, transtypage à en veux tu en voilà et j'en passe) et lent (puisqu'interprété).

Je me garde en réserve les arguments pour, ce n'est pas le sujet du débat.

[laffreuxthomas]

aaaah ! c'est sympa d'avoir remis au goût du jour ce vieux sujet !

pour SQLPRO, j'aimerais savoir dans le cas d'access s'il fonctionne de la meme maniere si par exemple je developpe cote client en delphi ou VB6

Je ne suis pas SQLPro mais oui, c'est en fait le driver ODBC côté client qui va ramener en local une copie du fichier et travailler dessus. Ne pas utiliser Access (stockage de données) pour autre chose que du développement / prototypage !

quel outil vous permet de développer une application aussi vite qu'Access

Mon mien, et 10 fois plus vite encore ! Fiable, multi-utilisateurs, avec des interfaces homogènes, indépendant de l'OS et du SGBD. Qui dit mieux ? Il est gratuit, open-source, ici : www.sashipamelba.com

C'est vrai que tu ne peux pas mixer du code VBA avec autre chose, mais tu peux appeler des API et gérer des objets COM. Que veux tu de plus ?

C'est vrai, je disais ça en ayant en tête un autre problème :

Pour un petit projet, bien souvent, on choisit Access car c'est la solution la plus légère. C'est d'ailleurs souvent l'utilisateur lui-même qui créera sa base Access. Ensuite, avec le temps, on ajoute des fonctionalités. Il arrive un moment où on est dans une impasse : la base et l'appli à (mal) grossi et il faut tout refaire dans une autre techno.

C'était dans ce sens que je parlais : impossible de récupérer le boulot déjà fait. Sur les autres plate-formes c'est moins critique car on n'est pas obligé de changer de techno quand le projet prend du poids.

Access ne gère l'héritage et l'encapsulation mais tu peux créer un objet et lui affecter des propriétés et des méthodes.

Je sais, ça a l'avantage de permettre de découper un projet plus facilement. Mais ça ne suffit pas pour en faire un langage orienté Objets.

<provoc>
C'est quoi, un langage professionnel ? Quelque chose qui t'oblige à tout faire à la main ?
</provoc>

Pas du tout ! C'est quelquechose qui te permette de tout faire à la main !

Tu peux aussi faire du code immonde avec Delphi.

Oui, mais ça n'est pas conseillé en Delphi alors qu'en Access c'est considéré comme normal.

Au fond ce que je reproche à cet outil, c'est son positionnement :
- facile d'emploi pour le néophite : ses assistants permettent au néophite d'obtenir quand même quelquechose
- déjà présent sur les PC utilisateurs, donc "gratuit" et déjà déployé
- petits projets uniquement

Le résultat, c'est que les projets Access ne sont pas professionnels.

Je n'aurai rien contre sauf qu'on demande après au professionnel de réparer les pôts cassés.

Maintenant, c'est imaginable qu'un professionnel puisse obtenir quelquechose de cet outil. A condition qu'il le fasse de A à Z. Mais dans tous les cas c'est une impasse à moyen terme. Donc ça n'est pas un choix professionnel.

Thomas

[laffreuxthomas]

Je me garde en réserve les arguments pour, ce n'est pas le sujet du débat.

Moi je veux bien les arguments pour. De toutes façons c'est une bonne stratégie de connaitre le point de vue adverse dans le cas d'une synthèse pour décideurs, donc ça fait partie du débat.

[P'tit Jean]

Mouais alors la faut arrete un peu de se "branler la nouille" (excusez moi l'expression) sur le terme professionnel Mr Laffreux!!

Moi aussi je suis dans le monde professionnel, moi aussi je bosse sur des grosses applications (pour les marches financiers des 3+grosses banques francaises) et crois moi je sais ce que sait qu'une tres grosse base de donnee (Oracle ou Sybase).

Maintenant ta reaction me pousse a croire que t'as jamais bosse avec une PME ! Tu sais la petite entreprise ou il y 1 a 15 personnes par exemple. Du style un agriculteur qui veut faire un relever de production de ces champs par exemple. Et alors tu lui conseille quoi ? Une base Oracle avec interface en Swing base sur des EJB en passant evidemment par une phase d'architecture sous Rationnal ?

Non non et non ! Access est un outil professionnel mais il est adapte a un certains type de besoin. Crois moi j'en connais des developpeurs qui gagnent tres bien leur vie en ne developpant que ce genre de produit (ex de l'agriculteur), c'est relativement simple a depanner par hot line puisque l'utilisateur n'as pas reelement besoin de rentrer dans des codes complexes, c'est pas cher du tout en comparaison du reste ...

Voila c mon coup de gueule, desole si tu le prends mal mais je suis completement en desacord avec toi sur ce point et je comprends et soutient parfaitement Le Vieux dans son discour.

Chaque probleme a une solution adaptee !

[Etienne Bar]

Merci p'tit jean, je me sens moins seul. Je suis effectivement un développeur qui s'adresses à des PME pour lesquels la majorité des projets font moins de 20 jours.homme (Oui, j'ai bien écrit moins de vingt). Moi aussi, j'en ai ras la casquette de m'entendre dire que je ne suis pas un professionnel parce que je dev. avec Access ! Faire du petit projet, c'est aussi un métier et c'est pas à confondre avec de la bidouille !

Envoyé par laffreuxthomas

Pour un petit projet, bien souvent, on choisit Access car c'est la solution la plus légère. C'est d'ailleurs souvent l'utilisateur lui-même qui créera sa base Access. Ensuite, avec le temps, on ajoute des fonctionalités. Il arrive un moment où on est dans une impasse : la base et l'appli à (mal) grossi et il faut tout refaire dans une autre techno.

Pourquoi "mal" grossi ? Dans mes dev access, c'est moi qui assure l'évolution. Et ça ne grossit pas mal.

Etant en train de passer à Delphi parce que les clients le demandent et la taille de certains projets l'exige, je peux te dire que je souffre quand je vois tout ce qu'il faut faire à la main là ou Access a des assistants visuels très sympas et efficaces (son QBE par exemple : le SQL a la mimine c'est rigolo mais quelle perte de temps !) ou fait le boulot tout seul. Pour l'instant, ce que je constate, c'est des temps de dev. qui explosent (bon, c'est vrai, faut prendre en compte le temps d'apprentissage...)

Envoyé par laffreuxthomas

C'était dans ce sens que je parlais : impossible de récupérer le boulot déjà fait. Sur les autres plate-formes c'est moins critique car on n'est pas obligé de changer de techno quand le projet prend du poids.

La, rien à dire, tu as raison.

Envoyé par laffreuxthomas

Oui, mais ça n'est pas conseillé en Delphi alors qu'en Access c'est considéré comme normal.

ce n'est pas plus conseillé avec Access qu'avec Delphi.

Envoyé par laffreuxthomas

Au fond ce que je reproche à cet outil, c'est son positionnement :
- facile d'emploi pour le néophite : ses assistants permettent au néophite d'obtenir quand même quelquechose
- déjà présent sur les PC utilisateurs, donc "gratuit" et déjà déployé
- petits projets uniquement

Le résultat, c'est que les projets Access ne sont pas professionnels.

Tu confonds outils et utilisateurs. C'est vrai que les bases Access developpées par des non-developpeurs pros d'Access sont souvent immondes. (ceci dit, la plupart remplissent quand même leur office -et ce n'est pas un jeu de mots- !)

Envoyé par laffreuxthomas

Maintenant, c'est imaginable qu'un professionnel puisse obtenir quelquechose de cet outil. A condition qu'il le fasse de A à Z. Mais dans tous les cas c'est une impasse à moyen terme. Donc ça n'est pas un choix professionnel.

J'ai un paquet d'applis Access qui tournent chez mes clients (la plupart depuis le sièce dernier ) et ils ne s'en plaignent pas.

Quand a ton outil qui est surement très bien (et dont l'applet de test ne fonctionne pas chez moi, mais il doit me manquer quelque chose), je serais pris qu'il m'offre toutes les possibilités de l'immonde VBA

[laffreuxthomas]

Coucou

Envoyé par P'tit Jean

Maintenant ta reaction me pousse a croire que t'as jamais bosse avec une PME ! Tu sais la petite entreprise ou il y 1 a 15 personnes par exemple.

Dans une PME non, mais dans 2 assos ce qui revient au même j'imagine. Sinon, de façon rémunérée, je n'ai jamais vu autre chose que des grosses boîtes. Bon, et dans les unes comme dans les autres on s'en mort toujours les doigts, des applis Access.

Surtout dans les assos. Mais je n'ai peut-être jamais vu d'applis correctement construites.

Inutile de se fâcher. Moi je continuerai à dire à chacun d'éviter de se mettre dans une impasse.

Même si je reconnais que aujourd'hui sur ce créneau Access n'a pas de concurrent, à part des solutions non relationnelles. En fait, c'est pour répondre à ce besoin dans les assos que j'ai créé ma techno.

Envoyé par Le vieux

Quand a ton outil qui est surement très bien (et dont l'applet de test ne fonctionne pas chez moi, mais il doit me manquer quelque chose), je serais pris qu'il m'offre toutes les possibilités de l'immonde VBA

Ah bon ? C'est une applet, donc il faut le plugin contenu dans le JRE de Sun. Mais elle marche parceque ce matin quelqu'un y a mis des c... que j'ai dû effacer.

Non effectivement ça ne t'offrira jamais toutes les possibilités du monde VBA, puisque c'est un outil de développement sans programmation.

Thomas

[laffreuxthomas]

Pourquoi "mal" grossi ? Dans mes dev access, c'est moi qui assure l'évolution. Et ça ne grossit pas mal.

Ok toutes mes excuses !

Manifestement on n'a pas le même parcourt. Mon expérience d'access est surtout associative. Grosso modo, quand je récupère une base Access bidouillée et re-bidouillée et re-re-bidouillée par 3 bénévoles différent, ça me fait regretter d'être bénévole.

En fait je reproche à Access d'être accessible par tous mais c'est vrai que du coup je confond l'outil et l'utilisateur dans mes critiques.

Non quand j'y pense, désolé, j'en ai quand même une sainte horreur !

Thomas

[Etienne Bar]

Envoyé par laffreuxthomas

Même si je reconnais que aujourd'hui sur ce créneau Access n'a pas de concurrent, à part des solutions non relationnelles. En fait, c'est pour répondre à ce besoin dans les assos que j'ai créé ma techno.

Ben voila, t'as la réponse

Ok toutes mes excuses !

Pas de quoi, on discute entre gens civilisés !

Non quand j'y pense, désolé, j'en ai quand même une sainte horreur !

C'est ton droit le plus strict. Moi, le peu que j'ai vu de Java, ca me donne envie de m'enfuir en courant ;-)