Vos recrutements informatiques

700 000 développeurs, chefs de projets, ingénieurs, informaticiens...

Contactez notre équipe spécialiste en recrutement

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

Le , par Maxence HUBICHE, Rédacteur
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 !


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de - http://www.developpez.com
le 16/09/2010 à 21:38
je ne veux ni froissez ni choquez quiquonque ou structure technique.
J'ai oeuvré pour du dévelloppement dans un team mais l'attitude de ces équipes est souvent bizarre. Ils devraient produirent pour répondrent aux demandes et les trois quart du temps, ils ne prennent même pas le temps de savoir qui fait quoi et comment chez leurs clients.
Deplus ces gens ont souvent des attitudes condescendants. (je sais hors sujet).
Moi ce que j'aprécie sur les sql server ce sont les vues qui n'existent pas (à ma connaissance ) en MySQL .

Par contre les requête imbriquées en access c'est pas le top.

Le reste me semble équivalent

jojo5650

lourdes; de plus ces équipes utilisent d
Citation Envoyé par Maxence HUBICHE  Voir le message
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 ?

Avatar de mandrake_of_mandregas mandrake_of_mandregas - Membre actif http://www.developpez.com
le 20/09/2013 à 16:37
Bonjour à tous,

php+mysql nettement supérieur en avantages, certains points ont été cités par les autres users, je voudrais en rajouter d'autre tout en développant certains aspects déjà cités.

1- Mobilité/continuité: l'application est accessible par tous les postes du LAN et même WAN. un incident technique sur un poste n'empêchera pas la personne de basculer immédiatement sur une autre unité tout en étant opérationnel dans les minutes qui suivent. pareil s'il est hors bureau et sur un autre poste que le sien. Sur Access ce n'est pas possible.

2- Les mise à jour affectant la structure de tables, formulaires, fonctionnalités ne nécessite pas de redéploiement, puisque c'est fait coté serveur. Contrairement à Access ou il faudra recompiler ton applicatif et le redéployer sur tous les postes quelque soit la mise à jour.

3- Traitement de taches Cron, en effet si on passe par un serveur Linux on profite de cette fonctionnalité.Ainsi on a la possibilité d'avoir des programmes php qui tournent en arrière plan sans intervention humaine et sans ressources supplémentaires, très utile pour les Reportings quotidiens et les alertes mails.
Contrairement à Access où il faudrait laisser l'applicatif ouvert sur un poste et nécessitant parfois une intervention humaine, sans oublier bien sûr de laisser l'ordinateur "non verrouillé".

4- traitement de gros fichiers CSV en un temps record, et qu'on peut également coupler au Tâches cron et ça donne des merveilles. Sur Access ce n'est pas évident il faut toujours avoir un applicatif qui tourne sur une machine et on risque d'avoir un dépassement d'index et un plantage de l'application sans oublier la taille du fichier qui augmente après chaque traitement même si on purge les données.

5- Dynamisme des formulaires : avec Php Mysq + Ajax/Jquery : on peut facilement gérer le dynamise de nos formulaires et ce dans l’ergonomie les contrôles et le contenu. Contrairement à Access, et si on tient compte des mises à jour dans ce volet bien précis Access devient un cauchemar.

6- le bundle Linux+apache+php+mysql est trés simple à installer et il est opérationnel en une heure à peine. SQLSERVER 2008 est un vrai case tête installation et gestion des tables sans parler des bugs et les mises à jour KBXXX et des différents conflits qu'ils peuvent causer si on installe une mise à jour au lieu d'une autre ou si on a installé sqlserver avant d'installer le service Pack etc.
Avatar de Tofalu Tofalu - Rédacteur http://www.developpez.com
le 22/09/2013 à 13:33
1- Mobilité/continuité: l'application est accessible par tous les postes du LAN et même WAN

L'application sera accessible partout où elle sera installée. Les données sont sur le serveur SQL et Access sert d'interface de saisie/consultation

2- Les mise à jour affectant la structure de tables, formulaires, fonctionnalités ne nécessite pas de redéploiement, puisque c'est fait coté serveur. Contrairement à Access ou il faudra recompiler ton applicatif et le redéployer sur tous les postes quelque soit la mise à jour.

Oui, encore que il serait possible de prévoir un système de MAJ comme sur n'importe quel soft.

3- Traitement de taches Cron, en effet si on passe par un serveur Linux on profite de cette fonctionnalité.Ainsi on a la possibilité d'avoir des programmes php qui tournent en arrière plan sans intervention humaine et sans ressources supplémentaires, très utile pour les Reportings quotidiens et les alertes mails.
Contrairement à Access où il faudrait laisser l'applicatif ouvert sur un poste et nécessitant parfois une intervention humaine, sans oublier bien sûr de laisser l'ordinateur "non verrouillé".

Pareil sur un Windows Server. Sans oublier les outils intégrés à SQL SERVER.

4- traitement de gros fichiers CSV en un temps record, et qu'on peut également coupler au Tâches cron et ça donne des merveilles. Sur Access ce n'est pas évident il faut toujours avoir un applicatif qui tourne sur une machine et on risque d'avoir un dépassement d'index et un plantage de l'application sans oublier la taille du fichier qui augmente après chaque traitement même si on purge les données.

Le SGBDR est SQL SERVER et non Access, ne confondons pas tout.

5- Dynamisme des formulaires : avec Php Mysq + Ajax/Jquery : on peut facilement gérer le dynamise de nos formulaires et ce dans l’ergonomie les contrôles et le contenu. Contrairement à Access, et si on tient compte des mises à jour dans ce volet bien précis Access devient un cauchemar.

De ce côté, je pense que la création et la maintenance de formulaire est bien plus simple sous Access. Ou alors, je n'ai pas compris votre remarque.
Avatar de mandrake_of_mandregas mandrake_of_mandregas - Membre actif http://www.developpez.com
le 23/09/2013 à 13:07
Citation Envoyé par Tofalu  Voir le message
L'application sera accessible partout où elle sera installée. Les données sont sur le serveur SQL et Access sert d'interface de saisie/consultation

Oui, encore que il serait possible de prévoir un système de MAJ comme sur n'importe quel soft.

Pareil sur un Windows Server. Sans oublier les outils intégrés à SQL SERVER.

Le SGBDR est SQL SERVER et non Access, ne confondons pas tout.

De ce côté, je pense que la création et la maintenance de formulaire est bien plus simple sous Access. Ou alors, je n'ai pas compris votre remarque.

Pour 1, l'application nécessite une installation de MS Office et configuration dans les sources de données. donc la mobilité et disponibilité sont nettement pénalisés, de plus sur un système équipé de Linux comment faire?

Concernant les mise à jour et le développement au fur et à mesure, la contrainte est bel et bien là à partir du moment où je dois prévoir des mises à jour ou des ajouts de fonctionnalités il faudrait donc ajouter au temps du développement le temps de redéploiement, essayons d'imaginer cela pour 50 postes...

3- ce n'est pas du tout pareil sur windows server+ Access on parle ici d'access et pas de sqlserver. Des tâches traités par access. sur PHP on peut écrire le script et faire en sorte qu'il soit lancé par la tache cron.

4- le traitement du fichier csv et la préparation de l'importation plus le travail à faire avant pendant et après importation ça se fait avec le langage pas avec le SGBDR.

5-Le problèmes du dynamisme est bel est bien existant et il est beaucoup plus compliqué sur Access, à titre d'exemple si on veut créer un formulaire avec des case à cocher dynamiquement générés par une requête qui elle même est dynamique... c'est pas aussi simple sur Access.

Le seul point fort Access est incontestablement les formulaires de tableaux croisés dynamiques là rien à dire. J'ai beau basculer vers php mais j'ai gardé un module reporting sur Access, un formulaire qui génère la requête et le formulaire Analyse croisé, Impeccable et en plus ça travaille directement sur les tables en temps réel et c'est rapide. Sur php j'ai beau essayé sans pouvoir atteindre le dynamisme et la fluidité de Accees, même les modules qu'on propose sur le web le font sur des fichiers CSv et pas directement sur les tables.
Avatar de Tofalu Tofalu - Rédacteur http://www.developpez.com
le 23/09/2013 à 13:22
Relisez le titre, il est bien question de la combinaison SQL Server + Access
Avatar de alassanediakite alassanediakite - Membre émérite http://www.developpez.com
le 24/09/2013 à 12:12
Salut
mandrake_of_mandregas voici quelques points...

coût
MySQL+PHP l'emporte.
Mais il faut savoir que
  1. MySQL n'est pas gratuit!!
  2. SQL server express + ACCESS runtime 100% gratuit!!!
    donc seul le coût de l'OS fera la différence.
!

Puissance du SGBD (SQL server VS MySQL)
SQL server+ACCESS l'emporte

Langage et technologie
SQL server+ACCESS l'emporte
MySQL+PHP
HTML
CSS
AJAX
APACHE
PDO/ORM/...
Sans compter les problèmes d'incompatibilité par browser (IE, Firefox, ...)
SQL server+ACCESS
VBA
ADO/DAO
pilote ODBC
Pour le redéploiement, un petit module s'en chargera.
A ce point il faut ajouter la rapidité de conception et la richesse incomparables des formulaires ACCESS à ceux de HTML.(même HTML5 rougira!)
Pour le cas de case à cocher que vous signaler, c'est plus simple que de l'eau à boire.
Après ça, les goûts et les couleurs ça ne se discute pas.
@+
Avatar de Tofalu Tofalu - Rédacteur http://www.developpez.com
le 24/09/2013 à 20:38
Ceci étant la solution php+mysql est plus portable.
Avatar de alassanediakite alassanediakite - Membre émérite http://www.developpez.com
le 24/09/2013 à 21:22
Salut
Citation Envoyé par Tofalu  Voir le message
Ceci étant la solution php+mysql est plus portable.

A mon avis, une explication du mot portable s'impose.
@+
Avatar de Tofalu Tofalu - Rédacteur http://www.developpez.com
le 25/09/2013 à 9:03
Dans le sens où l'application développée est (ou peut-être) compatible PC, Mac, Linux, smartphone, tablette
Avatar de Pierre Fauconnier Pierre Fauconnier - Responsable Office & Excel http://www.developpez.com
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.
Avatar de loufab loufab - Rédacteur/Modérateur http://www.developpez.com
le 08/10/2013 à 17:40
Je ne dirais qu'une chose pour relancer le débat.

http://www.developpez.com/actu/54053...e-vers-sa-fin/
Offres d'emploi IT
Ingénieur backend h/f
SHOPEDIA - Ile de France - Paris (75008)
Développeur(se) Java expérimenté(e)
LivingObjects - Midi Pyrénées - Toulouse (31000)
Business solution manager maris h/f
Marsh SA - Ile de France - La Défense

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique SGBD & SQL