Portekoi Posté 24 Février 2005 Posté 24 Février 2005 Complètement d'accord mais ne pas oublier que, parfois, l'open source n'est pas aussi puissant ou pas véritablement la réponse à un besoin et que le 'close' souce reste une solution. C'était Portekoi en direct de Paris; à vous webmaster Hub
destroyedlolo Posté 25 Février 2005 Posté 25 Février 2005 (modifié) Salut aussi, Salut, Dans beaucoup d'entreprises où j'ai bossé, elles étaient toutes en Asp ou .net. Pourquoi? parce que microsoft assure un suivi de leurs différentes machines ( moyennant finance biensûr ). Je suis actuellement dans une banque et c'est le cas. Je bosse aussi dans une grosse boite et j'ai bosse dans une SSII ou j'ai bosse aussi pour des gros clients : jusqu'en 98-99, une solution SQLServer/IIS avait le vent en poupe pour cette raison. Sauf que beaucoup se sont casse les dents a cause : - manque de securite (il fallait une solution exterrieur pour la secu et ca revient vite tres cher), - manque de stabilite, - mises a jour necessaires trop nombreuses, - manque de souplesse et de "scalability", ou alors ca reveint tres cher, - des commerciaux M$ qui vendent n'importent quoi : les clients sont decus et quant le R.O.I est loin de celui presente, ils choisissent une autre solutions rapidement. En plus, maintenant, beaucoup de boites comme HP ou IBM proposent aussi des solutions clef en main sous Nunux, alors le soit disant support M$ien rentre beaucoup moins en ligne de compte. De plus, je sais plus qui parle de Sql server en disant que mysql, c'est très bien et gratuit Sql server, c'est très bien et très cher. Je pense que tu as un sacré préjugé là dessus. Démontre moi que mysql fait aussi bien que Sql server. Les procédures stockées sont intégrées à la dernière version de Mysql, certes. Mais Lots DTS, Trigger, Cube Olap etc... niet. PostgreSQL les supportent sans doute (heu, peut etre pas le Cube Olap paske je ne sais pas ce que c'est). Niveau DB, actuellement a mon taf, le choix est : - mySQL pour les ch'tit trucs (comme tu le dis, il manque des fonctionnalite), - Oracle pour les trucs critiques ... Je bataille pour faire accepte Postgres pour les truc pas critiques mais qui ont besoin de toutes les fonctionnalites, ce qui nous couterait beaucoup moins cher qu'Oracle pour le moindre petit truc ... Moi je dirais que si c'est une petite boutique générant peu de trafic, php/mysql, c'est largement suffisant.Par contre, si c'est pour un gros site, Asp.net-php/Sql server/Oracle, c'est mieux. Mouai, de mon experience, c'est plutot : - php/mysql pour les petits trucs - php/postgresql pour les trucs necessitants beaucoup d'update live ou en //, ou pour la migration d'applie deja existantes avec plein de procedures stoquees et autres ... - ASP/.net avec SQLServer ou Oracle pour rentabiliser d'eventuelles investissements sur cette plateforme, mais pas pour du critique, - PHP ou JEE avec Oracle sous un unix quelconques (Nunux, Solaris, HPUX, AIX, ...) pour les applies solides, critiques avec beaucoup de gens qui vont dessus en simultanee, beaucoup de data et beaucoup d'updates. Heu, eviter les usines a gaz genre Oracle Portail car c'est hyper lourd, tres cher et pas genial niveau archi : bref, ca coute cher et c'est pas performant. Lolo Modifié 25 Février 2005 par destroyedlolo
Anonymus Posté 26 Février 2005 Posté 26 Février 2005 Pour info, après une étude menée par des universitaires : Windows Server 2003 serait plus sécurisé que Red Hat Linux.
Portekoi Posté 26 Février 2005 Posté 26 Février 2005 (modifié) Salut, Je vais pas reprendre ton post point par point car je n'ai pas le temps. Ton post me fais penser à quelqu'un qu n'a jamais travaillé avec SQL Server... ou du moins, pas à fond Prends postgresql , injecte lui 7 millions de ligne et fais de même dans Sql server. Tu verras par toi même Maintenant, c'est sur que pour une petite appli, faut pas sortir le tank ++ Portekoi Modifié 26 Février 2005 par portekoi
Antoine Cailliau Posté 27 Février 2005 Posté 27 Février 2005 Pour moi asp et php se valent mais l'asp.net apporte une réelle plus value.
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant