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]

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 ?

[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.

[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.

[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]

Je pense que vous n'avez pas bien compris mon propos. Et, si vous l'avez mal compris, c'est que je me suis mal exprimé. Ce qui m'ennuie, c'est qu'on est HORS DEBAT. Le cas eéchéant, je couperai la discussion...

Je vais donc me reprendre et vous allez voir que c'est évident. En tous cas, après en avoir débattu plusieurs heures avec le directeur informatique d'un grand groupe pharmaceutique, il a fini par acquiescer mon propos, ce qui me laisse à penser que je ne suis pas dans le faux...

Je dis :

• les développements longs sont un mal nécessaire pour avoir quelque chose de stable, bien pensé, perenne dans le temps
  =>Je pense que, sur ce point, nous sommes d'accords
• les développements faits par les utilisateurs sont des aberrations
  * Ce n'est pas leur job, ils ont suffisamment de taff comme ça pour se rajouter ça sur le dos
  * Ils n'ont pas la formation pour faire quelque chose d'efficace
  * En cas de seuil de compétence ou de bug, c'est l'info qui récupère le bébé
  =>Je pense que, là aussi, nous sommes d'accords
• L'utilisateur doit pouvoir travailler sans attendre le bon vouloir de l'informatique, parce que c'est pour cela qu'il est payé
  =>Personne ne s'oppose à ce point de vue je pense

Alors quid de cette idée de "coin de table" ?

Le service informatique devrait prévoir une équipe de VRAIS développeurs, intégrés à l'équipe informatique, qui ait :

Du point de vue de l'utilisateur, pour unique rôle, de répondre à son besoin immédiat, afin qu'il ne se préoccupe pas de programmation, mais de production.
=> Le programme est vite fait... et bien fait
=> le code est documenté
=> la convention de dénomination de l'entreprise est respectée
=> le SI garde la main sur le développement, puisqu'il n'est pas passé chez l'utilisateur
=> l'utilisateur n'endosse pas le rôle de développeur

Du point de vue du SI, pour rôle de remonter l'ensemble des besoins exprimé, mais également, les solutions mises en place.
=> l'ensemble de ces remontées sera recoupés par le nombre de demandes
=> sera priorisé
=> permettra la définition d'un cahier des charges
=> permettra une véritable analyse des véritables besoins des véritable utilisateur (pour éviter les développement SAP après audit des comptable pour un usage par le contrôle de gestion ... par exemple ...)
=> permettra donc d'implémenter des solutions perennes dans un SI stable, avec un développement à cycle long, et ce, sans avoir pénalisé, dans l'immédiat, l'utilisateur.

Du point de vue de l'entreprise, travaillant en tant qu'interface entre les utilisateurs et l'informatique, le fossé existant entre ces deux mondes va tendre à disparaitre car, le jour ou le développement cycle long, intégrant le besoin X exprimé 5 ans avant sera mis en prod, les membres du groupe pourront facilement identifier les personnels à l'origine de la demande et leur montrer à quel point leurs désirs ont été pris en compte, au point d'en faire un outil intégré à l'entreprise. D'autre part, en cas de changement important de la structure des données (par exemple) le groupe en question pourra intervenir directement sur leurs développement "coin de table" pour faire des mises à jour quasiment transparentes pour l'utilisateur final, ce qui permettra la maintenance, par des pros, d'applications, en attendant la prise en compte du besoin dans le SI.

On a donc, meilleure communication, donc meilleure collaboration, donc une meilleure ambiance, donc meilleure production. On a également une sécurité et une solidité des développement accrues. On a aussi une meilleure analyse des besoins puisqu'on est au plus près de l'utilisateur et qu'on récupère ses demandes au fil de l'eau.

Plus clair comme ça ?

[Tofalu]

Plus clair comme ça ?

oui

[SQLpro]

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.

Expérience d'il y a quelques années :
Un grand compte de la grande distribution à mis quelques millions sur la table pour expérimenter divers sites webs et technologies... Bilen des opérations :
PHP/MySQL : dérapage des projet, aucune tenue ni à la concurrence, ni au volume des données.
ASP/SQL Server : aucun dérapage des projets, tenue à la concurrence et au volume des données.
Ces projets ayant été multiples (près d'une dizaine) et réalisées par différentes équipes montées par différentes SSII très spécialisées chacunes dans leurs techno....

A +

[chaplin]

..
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.

Expérience d'il y a quelques années :
Un grand compte de la grande distribution à mis quelques millions sur la table pour expérimenter divers sites webs et technologies... Bilen des opérations :
PHP/MySQL : dérapage des projet, aucune tenue ni à la concurrence, ni au volume des données.
...

Quand je vois cette solution, l'affirmation n'est pas tout à fait vrai, dans la guerre commerciale, toutes les méthodes sont bonnes pour attirer de la clientèle, un procédé analogue est utilisé pour PG, c'est pas pour rien que les bases de données Open Source les plus médiatisées dans une certaine presse informatique sont aussi populaires .

[Tofalu]

Quand je vois cette solution, l'affirmation n'est pas tout à fait vrai, dans la guerre commerciale, toutes les méthodes sont bonnes pour attirer de la clientèle, un procédé analogue est utilisé pour PG, c'est pas pour rien que les bases de données Open Source les plus médiatisées dans une certaine presse informatique sont aussi populaires .

Sauf erreur de ma part, le sujet cité ne parle pas de MySQL

[chaplin]

Un ersatz, bien que le terme est fort mal convenu, mais au final on parle bien de MYSQL-PHP.

[dtravailloux]

Bonjour à tous.

Pour ma part, voici quelques éléments qui me font choisir un logiciel plus q'un autre selon les besoins exprimés dans le CDC.

Mysql4+ : bases de données pour site web. On écarte mysql quand on fait un site web dans le cas où il y a de fortes passerelles avec nos bases métiers et des processus d'alimentation remontants et descendants (nos bases métiers sont sur MSSQL). Il existe des solutions pour remédier à cela mais utiliser les PS et Vues de MSSQL dans nos applications web est efficace, simple à mettre en oeuvre (PHP communique très bien avec MSSQL).

SQL SERVER 2005+ : utilisé pour un observatoire économique régional. 12 CCI qui font du reporting avec cognos en attaquant MSSQL, mirroring des bases de données, fail over automatique, réplication de données..des mécanismes "relativement simple" à mettre en oeuvre. Une sécurité intéressante. Un management studio efficace (quoiqu'on arrive mieux parfois à faire ce que l'on veut par scripting T-SQL). Supporte bien la charge (toutes nos applications métiers tournent dessus, 160 collaborateurs).

Je crois qu'il y a beaucoup de facteurs qui rentrent en jeu dans la décision finale et il est sensible amha de généraliser.

a++

[mon_nom_est_personne]

D'abord je me permettrais de pose une question a l'auteur du post (desole j'ai oublie le nom) : demandes-tu un avis sur les deux solutions dans quel cadre ? car a premiere lecture du sujet je pensais qu'on parle en terme d'administration de bdd, apres en lisant les posts je pensais qu'on parlait d'application metier et maintenant je suis perdu dans des conciderations d'application web standard.

Je vais donc donne mon avis dans les 3 cas.

Administration: Rien a redire, du sqlserver/sql manager c'est le panard comparer a du Mysql/phpMyAdmin (je trouve phpMyAdmin de plus en plus pouringue avec le temps). Bien que Mysql/Mysql workbench est tres tres bon aussi.

Appli metier: J'ai jamais rellement fait de access donc je passe. Mais on a mis en place un gros extranet pour une tres grosse boite pharmaciotique en php/Mysql et les gens adorent le cote "pas de fenetre grise" et d'avoir quelquechose qui se rapporche de ce qu'ils voient tout les jours sur internet.

appli web: bataille de cloche encore et encore "php c'est lent, c'est freestyle, c'est pas secure, ca tiens pas la charge etc...". C'est tellement vrai que yahoo et facebook sont des plantages monstre qui se font voler leur donnees tous les jours. Sans oublier que c'est depuis peu qu'on peu faire du mvc en .net alors que ca fait tres longtemps qu'on en fait dans le monde du php.

Toujours est-il, je pense pas qu'il y ai de "technologie meilleur qu'une autre", il n'y que des "technologies mieux adaptees a un certain type de projet que d'autre".

[Scorpe51]

Bonjour à tous!

Je vais apporter ma modeste contribution à cette discussion, tout en essayant de rester le plus objectif possible (... disons dans mon argumentaire en faveur de PHP).

J'ai eu affaire à du développement Access (mais uniquement Access, pas de connexion à un serveur externalisé).

Je suis passé depuis dans le développement d'applications web (certaines en milieu professionnel, d'autres non mais en restant dans un cadre de développement rigoureux).


Pour cet argumentaire MySQL, je veux juste préciser que PHP permet de se connecter et d'utiliser SQL Server. Je ne vois donc plus de débat entre ces deux bases de données, puisque l'utilisateur peut choisir entre beaucoup de systèmes de base de données, et en général le développement se fait de manière transparente grâce à des couches d'abstraction.

Du reste, lorsque l'on parle de ce langage, PHP a été reconnu pour avoir atteint une certaine maturité depuis ses dernières versions. Evidemment, on lutte souvent contre les idées qui restent dans les esprits depuis des années pour se refaire à neuf. Ce langage est souple, supporte l'orienté objet et a une communauté d'aide et de développement très active.

Il est vrai, du fait de son interprétation (ce langage n'est pas compilé mais interprété à la volée), qu'il peut souffrir en comparaison à du C++ compilé par exemple d'une sacré lenteur. Je ne veux pas faire d'hors-sujet vu que l'on compare ici à du Access, et donc du vba (propriétaire microsoft et interprété également il me semble?).

J'ajoute comme point que s'il ne s'agit que de traitements intrinsèques à la base de données, PHP ne fait que rapatrier les données et les afficher, la rapidité du script dépendra donc de la base de données.

Pour le choix, tout dépend bien évidemment du type d'application à gérer. Cependant, on assiste aussi à une évolution considérable aujourd'hui du web, qui est définitivement ce vers quoi se tournent les utilisateurs (applications Word/Excel en ligne, etc...).


Pour ce qui est du design, le web offre des interfaces et une ergonomie très personnalisable, et il peut s'avérer très élégant et professionnel si le travail est réalisé avec application, et bien pensé. Le tout dynamique avec des interactions dignes d'applications de bureau!

De plus, attention, PHP n'est pas en relation directe avec le client: leur application se fait à travers leur navigateur qui reçoit du HTML/Javascript à traiter. PHP est transparent pour eux.

J'ai connu un gros logiciel, un ERP (Enterprise Resource Planning) qui gérait d'énormes volumes de données à travers une base oracle, et dont l'interface entre la base de données et le serveur web du client se faisait par Java.
Java, qui, pour les applications web (JSP), s'apparente à PHP sur le principe.


En réalité, veuillez m'excuser je crois qu'il s'agit plus d'une éloge aux applis web étant donné que je ne donne pas vraiment les avantages d'Access et inconvénients de PHP (mais d'autres sur ce sujet s'en sont très bien occupés ).

J'espère que cela sera utile, mais je rejoins d'autres commentaires: le développement et le choix d'une application et de ses langages dépend des besoins des utilisateurs. Il faut cependant pour faire son choix connaître tous les avantages et inconvénients, je crois que c'est ce qui se déroule dans cette conversation.

Bon courage!

[SQLpro]

Je n'ai pas contesté PHP... Malgré que quelques un l'on cru. PHP est bien plus sérieux que Access en terme d'outil client de développement d'application attaquant une bases de données. Je parlais dans mon précédent post uniquement de la comparaison entre les deux SGBDR

De nombreux sites utilisent le couple PHP/SQLserver. L'un des plus gros que je connaisse en profondeur (si j'ose dire...) est sexy avenue... Ne rigolez pas, la sté DREAMNEX qui s'en occupe est côté en bourse (j'entends encore des ricanements...). Le site est répartit sous de nombreuses enseignes donc différents DNS.
PHP est même aujourd'hui enrichit par des apports de Microsoft, qui y voit certes un concurrent, mais aussi un partenaire et préfère donner des addons à PHP pour l'orienter vers SQL Server que de le voir dans le giron MySQL... D'autant que MySQL AB, la sté commerciale qui à créé cet ersatz de SGBDR a été vendue à Sun puis Oracle, concurrent direct de MS !

Pour Access, il suffirait de demander à Rudi ce qu'il en pense... Il est en train d'essayer de bricoler une application d'un de ses clients qui est développé en Access/SQL Server. C'est tellement merdique qu'il à renoncé du fait des nombreux bugs à faire propre en invoquant des méthodes de forms en forms, pour ne plus faire que du copier coller de code, qui est la seule chose à peu près sure en matière d'appel !

Et il y a longtemps que je dis d'Access que ce n'est pas un outil de développement, ni pour les IHM, ni pour la base, mais un outil de bricolage pour adolescent boutonneux... (je vais pas faire plaisir à Maxence Hubiche)

A +