Avantages et inconvénients de PHP+MySQL contre Access+SQLServer ?

Membre éclairé

Le 19/06/2009 à 13:54

Bonjour,

D’habitude je ne rentre pas dans ce genre de débat, c’est une première car pour moi tout est bon.

Déclaration des constantes

On se dit que se qui compte c’est le sourire et les remerciements du client
Tout est du business et tout se termine par un chèque
Il y a des outils pour faire ceci et d’autre pour faire cela
On a ou pas la compétence par rapport a un contexte donné
On ne remet pas en cause une stratégie système parce qu’elle ne se situe pas dans un environnement familier
Les gens qui ont bossé à la conception des outils ne sont pas tous des cancres sans objectifs définis

Moralité
Il ne faut pas faire de comparaison inutile entre une pince et un marteau ou entre une masse et un marteau de matelassier.

PHP et mysql sont superbes dans bien des contextes (j’utilise d’ailleurs une connexion entre access et mysql pour le back office d’un site Web, aller, le seul reproche que j’ai se situe au niveau des mises à jours de composants sur la distribution linux utilisée)
Ms Acces est un RAD extraordinaire qui bombarde
Visual Studio 2008 no comment c’est infernal au niveau de la puissance

A+
ps : j'aime bien le vbscript aussi

2

0

titach

Candidat au Club

Le 11/06/2009 à 23:16

Salut,

Éternel débat sur les technos à utiliser !!
"Ouaiiiis, mais tu comprennnnds, le PHP c'est de l'interpretééééé alors forcément, c'est plus lent !"
=> dans ce cas, un seul critère, le temps d'affichage de la page (du point de vue client/utilisateur)
"Ouaiiiis, mais avec Access, c'est pas structurééééé, bonjour la maintenance"
=> trop de bugs (du point de vue client/utilisateur)

D'ailleurs, je vois d'ici les développeurs Java morts de rire à lire cette discussion (désolé, je parle français). Cela dit, j'en connais quelques uns qui ne devraient pas rire trop vite.

Bon.

Récemment, j'ai bossé sur la migration d'une appli Access/Access vers Access/Mysql pour des questions de volumes de données

Et sur une évolution d'appli PHP/MySql (récente en plus et développée en "objet"

Et ben je vous assure qu'on peut faire de la mer.. dans les 2 cas.

Une application mal et/ou trop vite conçue vieillit mal : chaque itération d'évolution tend à évoluer vers l'application plat de nouilles.

D'ou :

1/ Comprendre
On étudie le besoin du client en vérifiant qu'on a bien compris à l'aide d'outils (dessins écrans, enchainements des actions, synoptique, UML use cases, ...). Ça ressemble furieusement à des spécifications fonctionnelles, ça , non ?

2/ Modéliser
La structure de la base de données constitue les fondations de l'application. Ça doit être conçu solidement (pour moi, c'est merise MCD, (MLD), MPD). Et on ne déroge pas lors des évolutions, même si c'est plus long que la bidouille. Et on ne dénormalise pas sauf pour des questions de perfs dans des cas très particuliers.

Corollaire 1 : on ne se lance pas dans le codage avant d'avoir modélisé son application
Corollaire 2 : un développement itératif est compatible avec une bonne modélisation des données

3/ S'affranchir de la technique
Si on peut coder en objet pour l'accès aux données (mapping Objet/Relationnel), ça permet de ne pas ré-écrire des requêtes SQL à tout bout de champ (c'est une source de bug en moins). Si en plus on a un générateur d'objet d'accès à la base (Propel en PHP par exemple), une grande partie du travail est déjà faite avec l'assurance de la solidité et de l'évolutivité. Et tant qu'on y est, utiliser un framework complet.

4/ Coder le métier de l'utilisateur
Avec tout ça, l'écriture du reste du code (le métier de l'utilisateur et l'ihm) doit se faire sans se poser la moindre question.

Ça doit pouvoir se faire avec n'importe quel langage un peu développé.
(cad en PHP bien sur

, naaan, allez, c'est juste pour troller )

Et ça dépend plus du développeur (ses affinités, ses croyances (oui, oui), son mode de pensée, son entreprise, ses clients ...) que d'une évaluation stricte des avantages/inconvénients de chaque solution.

Cela dit, comment développer facebook ou Yahoo en Access ?

A+

Ah, heu, une petite chose encore, l'erreur se produit souvent entre le clavier et la chaise.

1

0

Yogui

Rédacteur

Le 12/06/2009 à 22:27

Envoyé par Tofalu

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é

Envoyé par 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.

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

Envoyé par SQLpro

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

Envoyé par Maxence HUBICHE

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

1

0

Tofalu

Expert éminent sénior

Le 23/09/2013 à 13:22

Relisez le titre, il est bien question de la combinaison SQL Server + Access

1

0

Pierre Fauconnier

Rédacteur/Modérateur

Le 26/09/2013 à 22:14

Au delà du fait que des discussions de ce genre virent assez vite au "J'aime mieux; j'aime pas", ce qui me fait sourire dans ce débat, c'est qu'au départ la question est mal posée.

Il ne peut pas s'agir d'un comparatif Access+MSSQL vs PHP+mysql, car si on s'en tient à cela, alors c'est Access+MSSQL qui gagne haut la main pour la simple raison que vous pouvez toujours essayer de faire tourner une appli avec seulement PHP+mysql. J'attends de voir le résultat.

PHP+mysql, ça veut dire qu'il faut au minimum du HTML + quelque chose côté client, en script ou autre. Et ça change quand même un peu la donne, il me semble. D'ailleurs, les avis argumentés en faveur de php+mysql spécifient tous qu'il faut "autre chose côté client" mais donnent, à tort à mon avis, l'impression que ce quelque chose est du domaine du trivial.

Je ne relèverai même pas les stupidités non argumentées éructées à propos d'Access pour gamin boutonneux.

1

0

Tofalu

Expert éminent sénior

Le 09/06/2009 à 22:10

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

0

ced

Rédacteur/Modérateur

Le 09/06/2009 à 23:25

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 :

multi-plateforme (alors que Access est limité aux OS Windows, je crois bien...) ;
implémentation du langage SQL : MySQL respecte plus le standard SQL que Access ;
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...);
gratuité et solutions libres (c'est un argument, tout-de-même, quand il faut payer plusieurs licences Access) ;
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

0

Tofalu

Expert éminent sénior

Le 09/06/2009 à 23:46

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 ?

0

Maxence HUBICHE

Expert éminent

Le 10/06/2009 à 6:56

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.

Multi-plateforme : Je ne peux pas dire grand-chose là-dessus... tu as raison et je ne compte pas tomber dans la mauvaise foi...
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
Performance en pool de connexion : Même remarques. Access seul, tu as raison. Mais Access + SQL Server, là... plus de problèmes
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.
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 !
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...
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 ?

0

Maxence HUBICHE

Expert éminent

Le 10/06/2009 à 7:00

Envoyé par Tofalu

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

Envoyé par Tofalu

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.

0

Identifiez-vous

Créer un compte

Avantages et inconvénients de PHP+MySQL contre Access+SQLServer ?

Identifiant
Mot de passe

Mot de passe oublié ?