IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

Sondages et Débats Discussion :

Avantages et inconvénients PHP+MySQL vs Access+SQLServer [Débat]


Sujet :

Sondages et Débats

  1. #21
    Expert éminent sénior

    Avatar de Tofalu
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Octobre 2004
    Messages
    9 501
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : Associations - ONG

    Informations forums :
    Inscription : Octobre 2004
    Messages : 9 501
    Points : 32 311
    Points
    32 311
    Par défaut
    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)
    Ca manque un peu d'argument là. En termes de développement d'une application de gestion, il n'y guère de différence avec une application développée en Delphi ... Si ce n'est qu'Access offre du DataBinding pour tous ses contrôles et ses forms.

    L'un des plus gros que je connaisse en profondeur (si j'ose dire...) est sexy avenue...

  2. #22
    Candidat au Club
    Profil pro
    Inscrit en
    Juin 2009
    Messages
    1
    Détails du profil
    Informations personnelles :
    Âge : 57
    Localisation : France

    Informations forums :
    Inscription : Juin 2009
    Messages : 1
    Points : 2
    Points
    2
    Par défaut Ben, on est pas sorti de l'auberge
    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.

  3. #23
    Expert éminent

    Avatar de Maxence HUBICHE
    Homme Profil pro
    Développeur SQLServer/Access
    Inscrit en
    Juin 2002
    Messages
    3 842
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Val d'Oise (Île de France)

    Informations professionnelles :
    Activité : Développeur SQLServer/Access

    Informations forums :
    Inscription : Juin 2002
    Messages : 3 842
    Points : 9 197
    Points
    9 197
    Par défaut
    Merci à tous pour votre participation, jusqu'ici


    Citation Envoyé par 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.
    Tout !
    Chacun des avantages et inconvénient peut être abordé.
    Comme je l'avais dit, du moment que c'est argumenté et pas seulement un avis tout personnel.

    Citation Envoyé par SQLpro Voir le message
    Pour Access, il suffirait de demander à Rudi ce qu'il en pense
    Rudi (que je ne connais pas) est-il une référence en terme de développement Access ?
    Cet argument est aussi valide que si tu avais dit :"Pour Access, il suffit de demander son avis à Maxence"
    Et pourtant, je suppose que tu aurais un avis tout à fait différent !

    Citation Envoyé par SQLpro Voir le message
    ... 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 !
    J'ai aussi toujours dit que, quel que soit le logiciel, la qualité du développement était le fait du développeur. Alors si ce Rudi fait de la m*****, il ne faut pas dire que c'est la faute d'Access !
    Dernièrement, j'ai formé un développeur avec 20 ans d'expérience. Il n'était jamais passé à l'objet. Il a découvert les classes et les évènements personnalisés, et on a fait diminuer le nombre de lignes de code de son appli par 2 !
    Moi, je développe en classes, collections, etc..., je prends le temps de modéliser, d'étudier, de faire valider, ... AVANT de me lancer dans le projet.
    Ben... mon code, il tourne, et il migre en quelques clics sur SQLServer. Mes projets restent en place plusieurs années. Je peux intervenir pour faire une modification d'interface en quelques minutes parce que c'est propre...
    Tout ça pour dire que, faire du copier-coller de code PHP tout pourrave c'est possible aussi, et ca ne fait pas de PHP une daube pour autant. Donc l'argument de dire que le fait qu'un gus quelconque fait du code tout pourri est la preuve qu'un produit est tout pourri me laisse pantois !
    Citation Envoyé par SQLpro Voir le message
    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)
    Ben, ca ne me dérange pas ! Quand tu connaitras Access, tu changeras d'avis

  4. #24
    Expert éminent

    Avatar de Maxence HUBICHE
    Homme Profil pro
    Développeur SQLServer/Access
    Inscrit en
    Juin 2002
    Messages
    3 842
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Val d'Oise (Île de France)

    Informations professionnelles :
    Activité : Développeur SQLServer/Access

    Informations forums :
    Inscription : Juin 2002
    Messages : 3 842
    Points : 9 197
    Points
    9 197
    Par défaut
    Citation Envoyé par titach Voir le message
    Cela dit, comment développer facebook ou Yahoo en Access ?
    C'est bien le souci !
    On ne fait pas de dev Web avec Access ...
    A ce sujet, SQLPro a raison :
    Citation Envoyé par SQLpro Voir le message
    A première vue cette comparaison est stupide :
    1) PHP c'est du Web. Access c'est du client lourd
    Maintenant, tu peux faire un ADP avec Access qui se connecte à une base SQLServer, et là, tu as du Vrai client-serveur, avec une vraie solution server pour les données, stable, solide, .... et un véritable RAD qui te permet de développer une interface très rapidement et efficacement.
    Donc, un FaceBook en client riche ... pourquoi pas !


    Je pense, d'ailleurs, que cette histoire de développement Web est la raison principal du passage de Access vers une solution PHP+MySQL
    Qui sait si un jour Access ne permettra pas de développer des application Web en relation avec un serveur MSSqlServer... waww !

  5. #25
    Membre régulier
    Inscrit en
    Février 2006
    Messages
    93
    Détails du profil
    Informations forums :
    Inscription : Février 2006
    Messages : 93
    Points : 109
    Points
    109
    Par défaut
    Allez, à mon tour de donner mon avis sur le sujet!

    Je ne reviendrai pas sur un débat côté SGBD, comme dit plus haut PHP permet l'utilisation de MySQL, MSSQL ou encore toute une palanquée d'autres SGBD. Pour ce genre de choix, je vous conseillerai de respecter l'avis de SQL Pro ;-) Je dirai juste qu'à mon avis MySQL tient la charge puisque à ma connaissance Wikipédia l'utilise comme BDD et point de vue charge, je ne pense pas qu'en entreprise on ait des contraintes de charge qui approchent celles de Wikipédia.

    En revanche je bosse actuellement sur une appli PHP dans une boite qui l'a récupérée d'une de ses filiales. Je vous confirme qu'on peut faire des grosses daubes quel que soit le langage utilisé mais je ne vous apprend rien n'est-ce pas.

    Par contre le GROS avantage que je vois dans les applications web par rapport au client lourd. Encore plus important que d'être multi plateformes c'est que vous n'avez plus à gérer le déploiement de votre client à tout votre parc info. Vous n'avez pas d'erreur du style "ah mais vous avez un client version 3.1 alors que depuis la semaine dernière on es passé à la 3.4". Là tout le monde utilise le même logiciel de A à Z, le déploiement aux utilisateurs est instantanné si vous changez votre interface et vous n'avez pas de risque d'incompatibilité avec une version d'OS particulière. Si les choses sont bien faites, vous n'avez pas non plus de différences entre navigateurs.

    Enfin, avec l'utilisation de frameworks php et d'ORM, on obtient une facilité de développement permettant de se concentrer de plus en plus uniquement sur le côté "métier" de votre code, avec un certain niveau de data binding. Cependant je ne pense pas qu'on atteigne ce qui se fait sous access (mais là ce n'est pas moi l'expert).

    Si ça peut aider!

  6. #26
    Membre éprouvé
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    1 044
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2006
    Messages : 1 044
    Points : 1 041
    Points
    1 041
    Par défaut
    Bonjour,
    le débat est assez compliqué.
    après une migration de ACCESS à sql server (Projet Ade) je pense passer au web.
    Mais les questions qui se posent sont comment faire pour réussir à faire de beau planning, Créer une arborescence, faire des graphiques, ouvrir n'importe quel type de fichier avec du php.
    Aujourd'hui je ne passerais certainement pas par le php mais par des outils visual studio avec des compléments client riches me permettant de faire ce que je souhaite.
    Donc ACCESS aura l'avantage d'etre facile de mise en oeuvre, rapide, Aussi efficace que n'importe quel langage si bien écrit (Les bugs que je rencontre aujourd'hui sont plus souvent du à mon manque d'attention qu'à access)
    faire a peu près ce qu'on veux.
    les inconvénients: ne fonctionne que sous windows (95% du marché) si il y a des modifs doit etre réinstallé partout, ne fonctionne pas en web sauf en tse, citrix ou autre.

    PHP (je ne connait pas)ou tout langage internet: Avantage installation à un seul endroit, utilisable sur web
    Inconvénients: pas encore possible de faire ce qu'on veux, mise en page galère. fait parfois ce que ça veut en fonction du navigateur, dès qu'on met des controls riche chargement plus lent.

    Ce n'est qu'un avis mais l'aspect web manque vraiment à ACCESS.

  7. #27
    Membre régulier
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    Février 2008
    Messages
    71
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet NTIC

    Informations forums :
    Inscription : Février 2008
    Messages : 71
    Points : 117
    Points
    117
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    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 +

    C'était effectivement il y a quelques années (une éternité pour PHP ! ), et la situation a bien changé.
    Certes, mysql reste plein de bugs, mais dispose aussi d'avantages certains, et de fonctionnalités généralement méconnues :

    - les performances en lecture en cas de très fortes charges (grâce à l'architecture en cluster de mysql et les performances du moteur myIsam).
    - le moteur innoDb (maintenu par Oracle), qui permet à mysql de rattraper son retard sur les autres SGBD (contraintes d'intégrités, procédures stockées, même si le PL/SQL n'est pas encore implémenté)
    - Sa facilité d'administration (via des outils clients, aussi bien en CLI qu'avec une interface graphique, ou via des outils web tels que phpMyAdmin)
    - Sa portabilité (il n'est pas nécessaire d'avoir un serveur sous windows pour l'installer, a peu près toutes les plate-formes disposent de leur version de mysql).

    Maintenant, il reste clairement en retrait par rapport à un oracle ou un SQL server.

    Pour revenir au sujet, je vois quelques arguments en faveur de PHP/Mysql (qui sont mon domaine), mais ils s'appliquent à des cas précis :

    - la mobilité (ça a déjà été évoqué, mais je pense que c'est extrêmement important à l'heure du travail nomade) : il est très simple et peu onéreux d'y accéder depuis n'importe quel PC dans le monde, alors que créer une connexion VPN via une carte 3G à l'autre bout du monde coûte vite une petite fortune

    - Le déploiement : Le déploiement d'une nouvelle version d'un outil web se fait à un seul point (le serveur). Pour un client "riche", il faut le déployer sur l'ensemble des clients (dans un grand groupe, on parle en milliers d'installations, avec des configurations différentes, donc des problématiques différentes... ) [EDIT : sujet déjà abordé, sorry j'avais loupé le passage]

    - Les développeurs :

    Le code PHP n'étant pas compilé, il est donc très facile d'en récupérer les sources si le développeur qui maintenait l'applicatif se barre avec son code (on récupère la version de prod).

    Pour moi, pour conclure, les 2 solutions sont viables, et chacune présente ses avantages / inconvénients en fonction du type d'usage et de l'évolution souhaitée.

  8. #28
    Rédacteur

    Avatar de Yogui
    Homme Profil pro
    Directeur technique
    Inscrit en
    Février 2004
    Messages
    13 721
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yonne (Bourgogne)

    Informations professionnelles :
    Activité : Directeur technique

    Informations forums :
    Inscription : Février 2004
    Messages : 13 721
    Points : 29 985
    Points
    29 985
    Par défaut
    Citation Envoyé par Tofalu Voir le message
    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é

    Citation Envoyé par SQLpro Voir le message
    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

    Citation Envoyé par SQLpro Voir le message
    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++...
    Citation Envoyé par Maxence HUBICHE Voir le message
    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

  9. #29
    Membre expert
    Avatar de alassanediakite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2006
    Messages
    1 599
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : Mali

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2006
    Messages : 1 599
    Points : 3 590
    Points
    3 590
    Billets dans le blog
    8
    Par défaut
    Salut Maître SQLPRO
    Je trouve que vous exagérez un peu ça...
    Citation Envoyé par SQLpro Voir le message
    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 +
    J'avoue avoir énormément appris (sql, modélisation, optimisation, l'explication des 12 règles de E F Codd ...) avec vous et cela exige mon respect.
    Mais là on vous demande des arguments, pas de dénigrer tout une partie (très grande) du monde des développeurs.

    Heureusement nos clients n'ont pas le temps de passer par là.

    Comme SGBD ,suivant les 12 règles, je croie avoir remarqué qu'ACCESS ne respecte pas qu'une seule a savoir gérer une base sans utilisation d'un fichier externe.
    Comme créateur d'IHM je me demande ce que les langages "pro" font qu'il ne fait pas. Mieux, sa communication avec les autres éléments d'office est sans égal et est de loin très bénéfique.
    Moi je dirais plutôt que les développeurs "pro" sont jaloux de voir que les débutants (adolescent boutonneux) puisse faire "quelque chose qui marche" sans avoir à "trop taper" et en "quelques clic".
    Pour moi la seule règle de choix reste "à César ce qui est à César"
    Il faut chercher à savoir ce que peut faire ACCESS, ce sera un plus...(bien que vous le maîtrisez mieux que moi)
    Merci pour vos multiples apports encore inépuisables.
    Le monde est trop bien programmé pour être l’œuvre du hasard…
    Mon produit pour la gestion d'école: www.logicoles.com

  10. #30
    Expert éminent

    Avatar de Maxence HUBICHE
    Homme Profil pro
    Développeur SQLServer/Access
    Inscrit en
    Juin 2002
    Messages
    3 842
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Val d'Oise (Île de France)

    Informations professionnelles :
    Activité : Développeur SQLServer/Access

    Informations forums :
    Inscription : Juin 2002
    Messages : 3 842
    Points : 9 197
    Points
    9 197
    Par défaut
    Citation Envoyé par Yogui Voir le message
    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
    Citation 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 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.

  11. #31
    Membre éclairé

    Homme Profil pro
    Inscrit en
    Juillet 2005
    Messages
    626
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : Juillet 2005
    Messages : 626
    Points : 726
    Points
    726
    Par défaut La ou les comparaisons
    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

  12. #32
    Membre régulier
    Profil pro
    Webmaster
    Inscrit en
    Mai 2008
    Messages
    281
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : Belgique

    Informations professionnelles :
    Activité : Webmaster

    Informations forums :
    Inscription : Mai 2008
    Messages : 281
    Points : 89
    Points
    89
    Par défaut
    Warg quel débat

    Dans un partage de cas vécu, voici brièvement mes choix: (je développe des applications métier en entreprise)

    Personnellement pour l'entreprise Mes 2 derniers projet développés sont sous les 2 technologies proposées (PHP and MySql et Acces via Runtime and SqlServer 2005)

    Première application sous SQL serveur, j'ai un formulaire complet pour le référencement d'article, je consolide 388 champs d'information nécessaire à alimenter notre système de gestion international (ERP - Navision)
    Navision étant sous SQL server 100% microsoft il est alors facile et logique de respecter la suite microsoft. et donc 140 utilisateurs internationnal (enfin presque) utilisent l'interface via runtime et toutes les tables sont sous SQL server. ça marche du tonner, et fluidité garantie...

    Mon deuxième projet c'est de faire une phothèque produit avec filtre et recherche, là je me suis intérogé sur le choix de la technologie, j'ai donc dévellopé les 2 ! J'ai fait une sous Access2007+sql et une autre sous PHP-MySQL

    Sous access, cela tourne bien évidement et fluidité aussi, mais j'ai trouvé cela assez rigide car chaque formulaire doit contenir des informations et doit être rédigés quasiment par automatisme.

    j'ai redévelloppé une autre gallerie avec PHP and MySql et la on augmente la flexibilité. mais moins de sécurité face à SQL serveur, backup automatique etc...
    Inconvéniant, il faut un serveur dédié à l'appli web et un serveur web, c'est assez lourd contrairement au standard SQL serveur...

    Je pense qu'il faut choisir en fonction du besoin, les 2 technologies sont intéressantes et à la fois alternative l'un en vers l'autre.

    ceci est mon avis. dans mon cas j'aurais bien aimé avoir toutes les application sous PHP car on met tout sur intranet et hop... on y va... mais c'est aps si facile que de le dire

    Bye
    Johan

  13. #33
    jojo5650
    Invité(e)
    Par défaut je partage ton point de vue
    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 ?

  14. #34
    Membre actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mai 2004
    Messages
    144
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : Vatican

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Mai 2004
    Messages : 144
    Points : 238
    Points
    238
    Par défaut
    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.
    .
    . . Savoir, savoir faire, faire , faire savoir...

  15. #35
    Expert éminent sénior

    Avatar de Tofalu
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Octobre 2004
    Messages
    9 501
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : Associations - ONG

    Informations forums :
    Inscription : Octobre 2004
    Messages : 9 501
    Points : 32 311
    Points
    32 311
    Par défaut
    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.

  16. #36
    Membre actif
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mai 2004
    Messages
    144
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : Vatican

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Mai 2004
    Messages : 144
    Points : 238
    Points
    238
    Par défaut
    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.
    .
    . . Savoir, savoir faire, faire , faire savoir...

  17. #37
    Expert éminent sénior

    Avatar de Tofalu
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Octobre 2004
    Messages
    9 501
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : Associations - ONG

    Informations forums :
    Inscription : Octobre 2004
    Messages : 9 501
    Points : 32 311
    Points
    32 311
    Par défaut
    Relisez le titre, il est bien question de la combinaison SQL Server + Access

  18. #38
    Membre expert
    Avatar de alassanediakite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2006
    Messages
    1 599
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : Mali

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2006
    Messages : 1 599
    Points : 3 590
    Points
    3 590
    Billets dans le blog
    8
    Par défaut
    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.
    @+
    Le monde est trop bien programmé pour être l’œuvre du hasard…
    Mon produit pour la gestion d'école: www.logicoles.com

  19. #39
    Expert éminent sénior

    Avatar de Tofalu
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Octobre 2004
    Messages
    9 501
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : Associations - ONG

    Informations forums :
    Inscription : Octobre 2004
    Messages : 9 501
    Points : 32 311
    Points
    32 311
    Par défaut
    Ceci étant la solution php+mysql est plus portable.

  20. #40
    Membre expert
    Avatar de alassanediakite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2006
    Messages
    1 599
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : Mali

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2006
    Messages : 1 599
    Points : 3 590
    Points
    3 590
    Billets dans le blog
    8
    Par défaut
    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.
    @+
    Le monde est trop bien programmé pour être l’œuvre du hasard…
    Mon produit pour la gestion d'école: www.logicoles.com

Discussions similaires

  1. Avantages inconvénients PHP - Access
    Par arthuro45 dans le forum Langage
    Réponses: 4
    Dernier message: 16/09/2011, 14h47
  2. Réponses: 0
    Dernier message: 10/06/2009, 00h06
  3. Migration PHP/MySQL => ASP/SQLserver
    Par djoyeux dans le forum ASP
    Réponses: 3
    Dernier message: 24/09/2007, 21h55
  4. [MySQL] [SGBD] Script PHP/MYSQL d'access FTP
    Par ChRom dans le forum PHP & Base de données
    Réponses: 1
    Dernier message: 09/01/2006, 02h52

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo