Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Arguments pour et contre Access ?
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]
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...
Access est mal sécurisé.
Access utilise un mode de verrouillage inadapté.
- 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 ....
je mettrai plutôt "ailleurs que sur l'intranet où il est stocké"
Code : Sélectionner tout - Visualiser dans une fenêtre à part Access ne peut pas être accédé via ODBC ailleurs que sur le serveur 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
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 +
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
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 :
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
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>
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 !
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.
WinDev
Le prix n'est pas le mêmeWinDev, Access est moins cher.
Normal : WinDev fait plus de choses.Le prix n'est pas le même
C'est vrai que sur le plan des nanas photoshopées il en fait des tonnes...Normal : WinDev fait plus de choses.
Bonjour,
Il s'agit de quelques cas, il en existe d'autres qui sont recensés dans mon tuto : http://loufab.developpez.com/tutorie.../optimisation/
Je t'assure que tout ce qui apparaît en mode Aperçu doit sortir à l'imprimante. Soit le code n'est pas placé ou il faut, généralement on met tout ça dans le Sur_Formatage de la zone concernée, soit le pilote d'impression éprouve quelques difficultés à tout imprimer (j'ai eu le cas il y a quelques années avec un pilote OCE), dans ce cas une bonne mise à jour devrait remettre ça en ordre.
L'éditeur en mode SQL est utilisé par très peu de gens. Généralement issus de SQL server , Oracle. En principe on l'utilise en mode générateur puis on passe en mode SQL pour faire des copier/coller. Mais c'est vrai qu'une petite évolution serait sympa.
Donc c'est le chargement qui est long. là il n'y a pas grand chose à faire, sinon de réduire la taille des fichiers (création de vignettes) pour améliorer le temps de chargement.
Cordialement,
je ne suis pas informaticienWinDev
access me permet de maquetter tres vite et sans ligne de code , ce que pourrait faire visuellement une future appli developpé.
windev demanderait a ce stade de savoir programmé. j'ai essayé, y compris via la recuperation d'une bases avec windev. il faut rentrer du code et programmer.
comme consultant, et pour faire l'analyse de multiples sources excel , access est tres pratique. on rapatrie les excels dans access, on a tout, on fait des requetes, des relations, des tables et la base contient tout , ce qui est pratique pour passer les donnés a un groupe de travail
en resumé pour moi, access n'a aucun concurrent sur ce segment , et sert bien le tissu des pme , ou des entités de plus grosse boites
apres, pour les programmeurs de sgbdr, c'est different
mais a mon sens, access est un vrai succes
Bonjour,
Je ne suis pas un pro mais tout juste un autodidacte qui ne parle même pas Anglais.
Je me suis lancé avec Access 2007 pour deux raisons.
Tout est traduit en Français donc compréhensible pour un âne comme moi.
J'ai du refaire un programme qui tournait sous MSDOS donc obsolète avec les nouveaux windows.
J'ai acheté des livres pour connaitre un peu de VBA, j"ai fouillé dans développez.com et j'ai réussi à faire un programme pour gérer notre l'hotel restaurant.
-Facturation
-Gestion des stocks
-Fichier clients
-Archives des facture sur 4 ans
-réservations
-gestion des Arrhes
-Divers graphiques (Nuitées et occupations,nombre de chambres louées par n°,chiffre d'affaire pour les déclarations de TVA....)
Pour moi,non Pro, Access est l'outil idéal et j'ai le plaisir de faire moi même.
a+
Bonjour,
Non tu n'as rien loupé, les requêtes objets de MS ACCESS ne supporte pas les commentaires. Par contre créer des requêtes ADO via VBA à destination d'un SQL Server, là tu peux faire ce que tu veux, sauf utiliser les spécificité des requêtes pour JET.- Editeur SQL qui ne reconnait ni les mots clef ni les commentaires ?
(ça me parait tellement dingue que je pense avoir loupé un truc)
C'est une option dans les... options access. Une simple case à cocher.- Editeur SQL qui ne reconnait pas la norme ansi par défaut (pourquoi ?)
En effet mais il existe toute une batterie de méthodes pour retailler les formulaires à la taille d'un écran. C'est plus contraignant que Swing mais largement plus rapide à mettre en ouvre et à maintenir.- Formulaires de taille fixes, donc non transposable sans modification sur une tablette de petite taille
Mise à part les index, il y a de nombreuses raisons pour que cela se produise (méconnaissance du produit). Voir mon tuto sur l'optimisation des applications. Pour exemple j'ai eu des tables de plusieurs milliers d'enregistrements avec des temps de réponse largement supérieur à Oracle. Autre fait important, la manière d'écrire les requêtes, lorsqu'on les tapes à la menotte sans réelle connaissance des interaction de Rushmore on peut tomber dans des pièges grossiers.- Lenteur incroyable dès qu'on dépasse 500 enregistrements (j'ai 82 colonnes dans ma table, qui contiennent des données basiques, chaines et integer)
Quelques cas :
Liaison entre 2 tables par un "Where Id=Id" au lieu d'un Join.
L'utilisation d'un Not In().
Les liaisons entre tables avec des index comprenant des Null.
Et surement le pompon d'or pour la dorsale paumée au fin fond d'une arborescence serveur de 200 sous répertoire en nom long.
Le composant OLE DWG c'est pas un développement Autodesk ?- Intégration d'objets OLE moins aboutie que ce que je pensais (je pensais intégrer des DWG Autocad à ma base, mais le résultat était vraiment inexploitable)
Là j'ai pas tout suivi. C'est encore lié à ce composant Autodesk ?- Fonction de dessin sur formulaire en VBA uniquement lors de la prévisualisation
Pour terminer il ne faut pas confondre MS ACCESS qui est un RAD pur et JET qui est sa base de données intégrée. Rien ne t'empêche d'y coupler Oracle, SQL Server ou MySQL du moment que l'ODBC est présent et il l'est pour la majorité des base de données du marché.
En effet il y a quelques défauts dans ce produit, mais pas forcément ceux qu'on croit.
Rassure-moi tes photos et images tu ne les as pas collées dans un champ OLE ?!!!
Les Union sont en général très lourd.
Cordialement,
Salut et merci de tes réponses,
Non je n'ai aucun de ces cas, mais je me suis mal expliqué, c'est lors de l'impression PDF de mes étiquettes que la lenteur survient, c'est + un problème d'impression.
Oui en fait le pb doit venir d'Autodesk, mais j’aurais pensé qu'Autodesk fasse l'effort pour que ça fonctionne avec Access, et non ça ne marche pas bien (afficher un dwg dans access)Le composant OLE DWG c'est pas un développement Autodesk ?
Non ce sont les méthodes de dessin sur état .Line, .print etc ...Là j'ai pas tout suivi. C'est encore lié à ce composant Autodesk ?
C'est vraiment dommage qu'elle ne fonctionnent qu'en mode aperçu
Pour moi le seul qui soit vraiment scandaleux (en 2014) est l’éditeur SQLEn effet il y a quelques défauts dans ce produit, mais pas forcément ceux qu'on croit.
J'ai vérifié ! (ma base à un an, je ne me rappelle pas de tout ...)Rassure-moi tes photos et images tu ne les as pas collées dans un champ OLE ?!!!
Les images sont dans des composants images (formulaires ou état) dont la source est une concaténation de 2 valeurs de champs + de paramètres écrits dans une table _PARAM_
à savoir chemin et extension
Cordialement,
Gérald
coucou tous le monde !
aaaah ! c'est sympa d'avoir remis au goût du jour ce vieux sujet !
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 !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
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.comquel outil vous permet de développer une application aussi vite qu'Access
C'est vrai, je disais ça en ayant en tête un autre problème :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 ?
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.
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.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.
Pas du tout ! C'est quelquechose qui te permette de tout faire à la main !<provoc>
C'est quoi, un langage professionnel ? Quelque chose qui t'oblige à tout faire à la main ?
</provoc>
Oui, mais ça n'est pas conseillé en Delphi alors qu'en Access c'est considéré comme normal.Tu peux aussi faire du code immonde avec Delphi.
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
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.Je me garde en réserve les arguments pour, ce n'est pas le sujet du débat.
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 !
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager