Discussion :

[Maxence HUBICHE]

Voilà une question très délicate...

Et, j'avoue qu'elle me travaille un peu, car nous sommes sur des domaines très différents.

D'un côté, des logiciels "gratuits" ou (mal)déclarés comme tels (MySQL et Php)
De l'autre, une gamme de produits payants (Access et SQLServer), mais avec des solutions gratuites (Access Runtime et SQL Express)

D'un côté un développement "léger", accessible depuis n'importe quel navigateur
De l'autre, un développement en client riche, nécessitant une version logicielle (Access ou Runtime)

Pourtant, je me dis qu'il y a des avantages certains à passer de Access à PHP+MySQL, mais que Access a tellement d'avantages que ce ne doit pas être facile quand même de se passer d'une interface de travail si efficace et agréable.
De la même manière, SQLServeur est quand même beaucoup plus intéressant à piloter avec l'Entreprise Manager que MySQL...

Bref, que donneriez-vous comme avantages et inconvénients aux dex solutions ?

Toute suggestion pour balayer l'une ou l'autre est ouverte !
Les partisans d'Access comme ceux de MySQL et de PHP sont les bienvenus, tant que le débat se fait HONNETEMENT.
J'apprécierai tout particulièrement les commentaires des Ex-Accessiens passé à MySQL+PHP, ainsi que l'inverse.

Merci à tous !

[Tofalu]

Bonsoir,

Ma première réaction à froid :

Je n'ai jamais aimé la navigation par page d'un client web ... Ca manque de souplesse et j'y perd mes automatismes là où une interface Windows permet de gérer facilement des dizaines d'onglets, des menus ...

Parti de ce constat, je ne suis pas vraiment objectif. La programmation Web m'a d'autant plus découragé que je n'y trouve rien d'attrayant dans la finalité.

Et à vrai dire dans le cas qui nous interesse ici, j'ai du mal à trouver des arguments qui pourrait aller vers une solution légère.

La portabilité ? Je ne sais pas si elle est vraiment de mise au sein d'un SI où, justement, il est question d'homogénéisation du parc.

Performances ? Dans un cas l'interface transite, dans l'autre seules les données font des allers/retours. Quel intéret du client léger ?

Sécurité ? Là, les avantages vont à mon avis à la solution riche face à l'ouverture du code de la solution légère.

Développement ? D'un coté des milliers de lignes de codes à écrire, de l'autre un RAD complet, intuitif et performant.

J'espère que certains vont pouvoir m'éclairer parce qu'honnêtement, dans le cadre d'un système d'information d'une entreprise, j'ai du mal à voir l'intérêt d'une solution Web, si ce n'est la portabilité dans le cas d'un parc hétérogène...

[ced]

Bonjour,

Pour ma part, je n'utilise pas Access.
Toutefois, en réfléchissant rapidement à cette question de comparaison, je vois les arguments suivants pour la solution MySQL + PHP :

1. multi-plateforme (alors que Access est limité aux OS Windows, je crois bien...) ;
2. implémentation du langage SQL : MySQL respecte plus le standard SQL que Access ;
3. performances avec d'importants pools de connexions (je crois qu'Access tient moins bien la charge en termes de connexions que MySQL, en tout cas pour les versions précédentes...);
4. gratuité et solutions libres (c'est un argument, tout-de-même, quand il faut payer plusieurs licences Access) ;
5. solution client léger : rien d'autre qu'un navigateur pour faire fonctionner l'application sur le poste de l'utilisateur...

Pour Access, l'un des avantages est sa facilité de mise en oeuvre. Pas besoin d'apprendre un, voire plusieurs langages de programmation (là où il faut connaître SQL, PHP, HTML et Javascript le plus souvent pour la solution PHP + MySQL).
La création d'un formulaire est beaucoup simple.

Mais ce qui est un avantage peut rapidement, en entreprise, devenir un inconvénient : il n'est plus possible de contrôler les applications développées autour d'une base Access, justement parce que le "développement" est à la portée de tous. C'est plus complexe et plus centralisé dans le cadre de PHP et MySQL, puisque ces applis nécessitent un serveur de base de données et un serveur d'application.

Voilà mes quelques réflexions à chaud. J'espère n'avoir pas dit trop de bêtises sur Access, que je ne connais vraiment pas bien (et qui relève plus, pour moi, de la bureautique... Aïe, pas la tête ).

ced

[Tofalu]

performances avec d'importants pools de connexions (je crois qu'Access tient moins bien la charge en termes de connexions que MySQL, en tout cas pour les versions précédentes...);

Attention, ici Access est l'appli (le client). Le serveur de données est SQL Server.

SQL Server respecte encore plus les standards que MySQL avec en plus les mécanismes propres aux serveurs de données (procédure stockée par exemple)
Quant à la charge, je ne saurais répondre en ce qui concerne mysql vs Sql server, même si je pense que le second l'emporte.

Mais ce qui est un avantage peut rapidement, en entreprise, devenir un inconvénient : il n'est plus possible de contrôler les applications développées autour d'une base Access, justement parce que le "développement" est à la portée de tous. C'est plus complexe et plus centralisé dans le cadre de PHP et MySQL, puisque ces applis nécessitent un serveur de base de données et un serveur d'application.

C'est un faux argument dans le sens où un projet Access compilé n'est pas modifiable alors qu'un code Php le reste. Sauf obfuscation peut être ?

L'avantage de Php+Mysql est comme tu le dis : le client légér qui permet un accès facile depuis le net sans se soucier des plateformes.
Si demain une solution locale souhaite être externalisée, il suffit avec Php+Mysql d'ouvrir le serveur sur l'extérieur. Dans le cas d'un projet Access, il faut tout repasser sur de l'ASP.NET lié au serveur SQL Server. Là, l'argument du coût est encore plus mis en avant : Coût minime au départ et aucun coût de redéveloppement en ce qui concerne Php, alors que si la solution SQL Server+Access avait été choisie je n'ose même pas imaginer l'écart de prix.

Mais au niveau ergonomie, une application windows ne vous paraît pas plus abordable et conviviale ?

[Maxence HUBICHE]

C'est un faux argument dans le sens où un projet Access compilé n'est pas modifiable

Quoique... une faille dans une certaine version ... mais bon, ce n'est plus valide maintenant donc... motus

Si demain une solution locale souhaite être externalisée, il suffit avec Php+Mysql d'ouvrir le serveur sur l'extérieur. Dans le cas d'un projet Access, il faut tout repasser sur de l'ASP.NET lié au serveur SQL Server. Là, l'argument du coût est encore plus mis en avant : Coût minime au départ et aucun coût de redéveloppement en ce qui concerne Php, alors que si la solution SQL Server+Access avait été choisie je n'ose même pas imaginer l'écart de prix.

Pour un cas pareil, j'aurai tendance à faire une migration sur MOSS... en quelques clics seulement depuis 2007.
Et là, l'écart de coût, c'est la plateforme MOSS.
Ce n'est pas le développement.

[Yogui]

C'est un faux argument dans le sens où un projet Access compilé n'est pas modifiable alors qu'un code Php le reste. Sauf obfuscation peut être ?

Il existe des solutions libres ainsi que des solutions commerciales pour de la pseudo compilation de code PHP, c'est à la fois de l'obfuscation et de l'optimisation. Bref, c'est un faux argument, il est possible de rendre illisible du code PHP. Et n'oublions pas que le client n'a pas nécessairement accès au code source puisque c'est du Web, il peut être simplement hébergé

A première vue cette comparaison est stupide :
1) PHP c'est du Web. Access c'est du client lourd
2) MySQL c'est du SGBD léger et farci de bugs y compris revendiqués (comme la fameuse date 0000-00-00 !) alors que SQL Server c'est du très lourd qui joue dans la cour des DB2 et Oracle.

J'ajoute que PHP est un langage de prog/script côté serveur, ce n'est pas côté client. Pour faie une appli Web, il faut au moins choisir :

• le stockage de données (SGBD ou autre, ici MySQL)
• le langage serveur (ici PHP)
• la techno client (HTML+JavaScript+CSS, Flash, applet Java, Silverlight, autre RIA) : tout est possible !
• + bien entendu les frameworks et autres patterns

PHP n'est qu'un langage serveur parmi d'autres. On peut faire des applis Web avec .NET/MySQL aussi bien que l'on peut les faire avec PHP/SQL Server. Avec un bémol toutefois dans ce dernier couple, j'y reviens plus bas

De nombreux sites utilisent le couple PHP/SQLserver.

Cela changera peut-être avec les prochaines DLL compilées sous VC9 (donc surtout à partir de PHP 5.3) mais, jusqu'à présent, les divers connecteurs SQL Server proposés pour PHP étaient plutôt de très mauvaises blagues. À moins, bien sûr, d'avoir les compétences en interne pour patcher le code C++...

J'ai aussi toujours dit que, quel que soit le logiciel, la qualité du développement était le fait du développeur.

Je vais terminer par un troll mais si tu laisses à tes développeurs le soin de faire la BDD sous SQL Server, tu aurais aussi bien pu choisir Access pour le backend...
À mon sens, la qualité du développement n'est pas le fait du développeur. Si tu laisses à ton développeur le soin de construire l'IHM + le schéma de la BDD + tout le reste, je ne suis pas tout à fait certain que l'appli tienne la route. Ou alors, augmente ton développeur et fais-en un chef de projet parce que tu as une perle bien rare

[Maxence HUBICHE]

Je vais terminer par un troll mais si tu laisses à tes développeurs le soin de faire la BDD sous SQL Server, tu aurais aussi bien pu choisir Access pour le backend...
À mon sens, la qualité du développement n'est pas le fait du développeur. Si tu laisses à ton développeur le soin de construire l'IHM + le schéma de la BDD + tout le reste, je ne suis pas tout à fait certain que l'appli tienne la route. Ou alors, augmente ton développeur et fais-en un chef de projet parce que tu as une perle bien rare

et moi j'ai di

J'ai aussi toujours dit que, quel que soit le logiciel, la qualité du développement était le fait du développeur

Je parle bien de développement et de développeur... Pas d'architecte ni de chef de projet...
Donnes une super base de données montée et concue par SQLPro lui-même, et sur SQLServer, en plus... et files ça à un développeur bidon, tu auras bien un développement bidon.

[Maxence HUBICHE]

Merci beaucoup pour ta participation Ced !
Etant donné le débat, je vais me permettre de jouer l'avocat du diable pour chaque intervenant. L'idée étant de retirer ce qui est VRAIMENT important, chacun ayant la possibilité de "défendre son beefsteak du mieux qu'il peut.

1. Multi-plateforme : Je ne peux pas dire grand-chose là-dessus... tu as raison et je ne compte pas tomber dans la mauvaise foi...
2. Implémentation du langage SQL : Oui, Access a son implémentation du langage SQL. D'un autre côté, l'activation d'une option permet de le rendre compatible ANSI92. Enfin, si tu couples Access sur SQLServer, là, tu ne te sers plus de Access pour la partie DATA et donc c'est SQLServer qui prend la main. De ce côté là, l'implémentation du SQL normatif doit même être meilleur que MySQL
3. Performance en pool de connexion : Même remarques. Access seul, tu as raison. Mais Access + SQL Server, là... plus de problèmes
4. Gratuité : Ben, de ce côté là, il y a un "manque de communication de la part de MS" ou un "manque de connaissance de la part de utilisateurs". En effet, Microsoft offre plusieurs solution gratuites et intervient beaucoup dans le monde du libre. Ce qui est peu connu, c'est qu'il existe une version gratuite RunTime (exploitation uniquement) d'Access. Donc, une fois le produit développé, il suffit de déployer le runtime pour que tout utilisateur ait la solution à sa disposition. Donc, je présume qu'on peut supprimer cette histoire de gratuité ou pas. Au pire, la limiter aux licences des développeurs. C'est leur EDI qu'ils achètent.
5. Solution Client Léger : Là, je pense que tu touches vraiment le point névralgique. mais je retourne la question dans l'autre sens : En PHP tu ne peux pas faire du client riche ... me semble-t-il
   D'un autre côté, si on pouvait développer depuis Access de véritables solutions pour clients légers, ce serait quand même un gros plus. Et je t'avoue que l'un de mes rêves serait de pouvoir développer avec les fonctionnalités d'Access, des clients légers liés à des bases de données SQL Server (Ah... le rêve)Enfin, pour terminer avec les clients "légers", il existe une solution de migration des données sur SharePoint, et une solution de migration plus complète de bases de données sur MOSS (avec les formulaires, états, ...) Toute la base est développée sur Access, et en quelques clics, on fait la migration. Pas mal hein !
6. Facilité de mise en oeuvre avec Access : Ouaip, je te rejoins ici. Même si le VBA reste à apprendre pour les néophytes. Mais il y a moins de choses à croiser quand même...
7. Perte de contrôle de l'application : Alors là, je vais être quasiment intraitable ! Cette perte de contrôle, c'est la faute des "informaticiens ! Quand un besoin est exprimé par un utilisateur, ils mettent 3 ans à sortir un projet qui réponde à ce besoin. Alors, l'utilisateur il se débrouille. Il a besoin de travailler, et pas d'attendre 3 ans ! Et comme les utilisateurs ont bien compris qu'ils ne pouvaient pas attendre que l'informatique se bouge, ils se débrouillent seuls. Cette perte de contrôle que déplore les services informatiques (pas les utilisateurs, au passage) est le fait des services informatiques eux-même. Normalement, s'ils prenaient vraiment soin de leurs utilisateurs, ils feraient eux-même les développements immédiats, sur le coin d'une table, pour répondre au besoin immédiat de leurs utilisateurs, pour qu'ils puissent travailler dans de bonnes conditions et pas faire leur travail + le job des informaticiens. Et s'ils agissaient ainsi, ils auraient toutes les billes pour, ensuite, intégrer ce qu'ils ont analysé comme besoin dans un développement à plus long terme. Et, dans ce cas, il n'y aurait plus de perte de contrôle, puisque l'utilisateur se retrouverait dans son rôle d'utilisateur, et le développeur dans son rôle de développeur, et le service informatique dans son rôle de SERVICE à l'utilisateur.

La bataille est ouverte !
Qui vient me fighter sur ces points ?

[qi130]

7 Perte de contrôle de l'application : Alors là, je vais être quasiment intraitable ! Cette perte de contrôle, c'est la faute des "informaticiens ! Quand un besoin est exprimé par un utilisateur, ils mettent 3 ans à sortir un projet qui réponde à ce besoin. Alors, l'utilisateur il se débrouille. Il a besoin de travailler, et pas d'attendre 3 ans ! Et comme les utilisateurs ont bien compris qu'ils ne pouvaient pas attendre que l'informatique se bouge, ils se débrouillent seuls. Cette perte de contrôle que déplore les services informatiques (pas les utilisateurs, au passage) est le fait des services informatiques eux-même. Normalement, s'ils prenaient vraiment soin de leurs utilisateurs, ils feraient eux-même les développements immédiats, sur le coin d'une table, pour répondre au besoin immédiat de leurs utilisateurs, pour qu'ils puissent travailler dans de bonnes conditions et pas faire leur travail + le job des informaticiens. Et s'ils agissaient ainsi, ils auraient toutes les billes pour, ensuite, intégrer ce qu'ils ont analysé comme besoin dans un développement à plus long terme. Et, dans ce cas, il n'y aurait plus de perte de contrôle, puisque l'utilisateur se retrouverait dans son rôle d'utilisateur, et le développeur dans son rôle de développeur, et le service informatique dans son rôle de SERVICE à l'utilisateur.

Qui vient me fighter sur ces points ?

Moi, moi !

Ce point ci-dessus est un débat presque aussi vieux que l'informatique. Je me garde bien de prendre parti, car selon moi, tout le monde a sa part de responsabilité dans cette situation, en premier lieu (puisqu'il faut bien commencer quelque part) les utilisateurs qui, ne comprenant rien au langage ésotérique des informaticiens, ont fait du lobbyisme afin qu'une Méthode soit mise en place.

Mais, ce n'est pas là le débat.

Par ailleurs, en faisant l'apologie de l'analyse/développement "coin de table", on favorise le phénomène bien (trop) connu aujourd'hui des fameuses failles logicielles. Le raccourcissement du cycle de développement, bien qu'il soit rendu nécessaire par la réactivité par rapport au contexte économique (par exemple), génère de facto ces bugs (cf. les bulletins hebdo de MS).

Enfin, je considère que favoriser l'essaimage du développement dans toute l'entreprise est une ineptie de par les dangers sécuritaires que cela fait peser sur le SI et donc sur l'entreprise elle-même.

Et croyez moi, en 20 ans d'informatique, j'en ai vu passer...

• La macro Excel qui devient une appli complète de gestion des instruments financiers. Le résultat semble bon, jusqu'au jour où on passe à l'euro...
• La même macro qui subi une montée de version du VBA et ne fonctionne plus à l'aide l'informatique...
• Le type qui l'a développé quitte l'entreprise
• Le PC qui héberge les sources est détruit, ou volé

Bref, je trouve que la lenteur d'un développement "professionnel" est un mal nécessaire car c'est un gage de qualité sur la durée.

Alors, pour en revenir au débat, je conçois bien l'utilité d'un tandem comme Access+SQLserver, tant que cela n'hypothèque pas la survie d'une entreprise.

Un des problèmes majeurs de cette approche est qu'on commence "pour voir", le plus souvent dans la clandestinité, et au mépris de quelques règles élémentaires qui font le quotidien des informaticiens.

[Tofalu]

Alors, pour en revenir au débat, je conçois bien l'utilité d'un tandem comme Access+SQLserver, tant que cela n'hypothèque pas la survie d'une entreprise.

Dans le cas d'un développement SQL Server + Access, on est plus dans la clandestinité d'une macro Excel mais sur un vrai développement professionnel. A moins que n'importe quel quidam ait la possibilité d'installer un serveur SQL sur son propre poste

Mais je dois avouer qu'en laissant l'argument "coin de table", Maxence a tendu le bâton pour se faire battre

[Maxence HUBICHE]

@Tofalu
Merci pour ton implication.
Je vais jouer l'avocat du diable avec tes avis également...

1. N'aime pas la navigation web : Ben... c'est ton avis, mais bon, c'est vachement subjectif quand même. Arguments ! arguments ! En plus, c'est quand même la solution d'avenir la virtualisation ET le web !
2. Portabilité : Selon moi, c'est un point clé ! Je suis sur mon poste de travail ... hop ! j'ai accès à l'information. Je suis en vadrouille, je sors mon PDA ou mon eeepc et hop ! j'ai acès à l'information ! Je vais chez un client, je me connecte au site concerné et hop ! j'ai accès à l'information ! Et ce, quel que soit mon PDA, le système de mon EeePC et la configuration des postes de mon client !
3. Performances : C'est vrai que là dans le cas d'une solution Access+SQLServer, c'est assez bluffant Mais bon, une appli web bien développée face à une solution d'interface Access développée par un pied, je pense qu'en terme de performances... c'est la solution Web qui l'emporte !
4. Sécurité : L'avantage d'une solution Access+SQLServer, c'est que la sécurité est déportée sur le serveur SQL (ouf!). Quand à comparer la sécurité des deux solutions, ben, si tu n'as pas les codes d'accès à PhpMyAdmin (ou s'il a été viré) tu vas t'amuser pour entrer dans ton serveur MySQL ! Quant à accéder aux pages de code php, c'est pareil ! Si tu n'as pas les codes du serveur, la seule chose que tu récupèreras, ce sera le code HTML généré par le serveur Web.
5. RAD : là, pas de souci, j'adère ! Mais d'un autre côté... ça n'existe pas un EDI graphique pour PHP ? (excusez mon ignorance...)

Le fight est ouvert

[Tofalu]

En effet mon non argument sur la navigation web est très subjectif (et j'avais prévenu ).
Cependant, il ne faut pas oublier que l’utilisateur possède ses propres habitudes. La secrétaire saisie ses courriers dans Microsoft Word, le gestionnaire fait du reporting avec Excel, le service marketing des présentations Powerpoint et tout ce petit monde utilise un client mail style Outlook. J’ai choisi ici des produits Office mais la comparaison serait la même avec OpenOffice.
Ce type d’application respecte un « standard » dans leur présentation et leur fonctionnement. L’utilisateur y a ses repères, ses automatismes (exemple de la fonction Annuler que l’on peut utiliser X fois).
En créant une application Windows le développeur part, à mon avis, avec une longueur d’avance au niveau de l’ergonomie et de l’image qu’il donne de son application à ses utilisateurs. Il n’y a pas pire sources de dysfonctionnement qu’un utilisateur qui n’a pas envie d’utiliser l’application. A voir le nombre de personnes qui ont crié au scandale lorsqu’elle ont vu le ruban, je me dis que je ne dois pas avoir totalement tord quand je pense qu’il ne faut pas les dépayser. Les utilisateurs attendent du développeur une solution qui leur ressemble et ce qui leur ressemble, c’est justement ce qui se faisait hier à savoir du Full Windows. Attention, je ne parle que de l’aspect de l’application, le client léger à ses avantages, la portabilité étant à priori le principal.

Jusque là, le sujet de l’interopérabilité avec les autres logiciels n’a pas été abordé. Sur ce point, et dans le cas d’une application de gestion, il me semble là encore qu’Access prend les devants. En quelques clics lignes de développements je génère des classeurs Excel, du PDF, des présentations PowerPoint, j’interagis avec le calendrier Outlook… En php, la solution paraît moins abordable, et le fait de vouloir travailler avec des documents sur le poste client complique d’autant plus la chose en ajoutant une couche supplémentaire : javascript.

Mais il manque quelque chose qui là se trouve sur les solutions légères : le tout prêt à adapter. Avec l’open source, il existe presque une solution déjà toute prête qui ne demande qu’à être adaptée. Chose que l’on ne retrouve pas sous Access. Cependant, il faudrait comparer ce temps d’adaptabilité à celui d’un développement complet et ce sur le long terme. Les temps de maintenances sont parfois décuplés avec des solutions qui prennent en compte des contraintes ou des spécificités qui n’existe pas dans le domaine de gestion concerné. Pour répondre à un besoin urgent, il se peut que le couple MySQL/Php prenne l’avantage tant autant de la mise en œuvre (installation, configuration) que de la réutilisation de briques.