J'utilise SQL Server depuis de nombreuses années sur des projets C # grands et petits, mais j'utilise principalement MySQL depuis un an sur divers projets C # (mais liés à l'open source et liés aux startups) qui utilisaient déjà MySQL.
SQL Server me manque ! D'après mon expérience, SQL Server est meilleur à bien des égards :
- l'optimiseur de requêtes dans SQL Server est plus intelligent, ce qui signifie que vous pouvez souvent créer des requêtes et qu'elles produiront des plans de requête optimaux. Avec MySQL, je passe plus de temps à régler manuellement des requêtes, même relativement simples, afin de produire de bons plans de requête.
- le moteur de base de données sous-jacent dans SQL Server peut faire une plus grande variété de choses pour améliorer les performances. par exemple, toutes les jointures dans MySQL sont des jointures de boucles imbriquées, tandis que SQL Server peut effectuer des jointures par hachage ou des jointures par fusion, ce qui peut parfois augmenter les performances des requêtes 10x+. SQL Server peut également paralléliser les requêtes, ce qui, en particulier pour les charges de travail importantes des entrepôts de données, peut considérablement améliorer les performances.
- les outils GUI ont une longueur d'avance. L'optimiseur de requêtes de plan graphique de SQL Server fait de l'optimisation des requêtes un jeu d'enfant - vous ne voudrez plus jamais revenir à EXPLAIN EXTENDED. Les outils de surveillance graphique de SQL Server 2008 sont tellement plus simples que de parcourir le journal des requêtes lentes pour déterminer ce qui ne va pas. Et ainsi de suite.
- Comme vous l'avez mentionné, l'histoire de l'intégration .NET (C#, Linq, Entity Framework, etc.) dans SQL Server est meilleure. J'utilise également C #, Entity Framework et LINQ avec MySQL, donc ce n'est pas une question de choix, bien que les performances soient probablement meilleures avec SQL Server dans un environnement .NET, car les équipes travaillent ensemble pour améliorer les performances et améliorer l'intégration. .
- La prise en charge du langage SQL de SQL Server est plus riche que celle de MySQL, y compris des fonctionnalités très intéressantes (en particulier dans SQL 2008) comme
ROW_NUMBER(),GROUPING_SETS,OPTIMIZE FOR, colonnes calculées , etc. - La sauvegarde est bien plus rapide, en particulier dans SQL 2008 avec des sauvegardes compressées
- Aucun nuage d'acquisition Oracle ne pèse sur l'avenir de SQL Server.
- SQL Server (en particulier les éditions coûteuses) est livré avec d'autres avantages, comme un entrepôt de données OLAP (SSAS), une solution de création de rapports (SSRS), un outil ETL (SSIS), un planificateur (SQL Agent), etc. Vous pouvez obtenez gratuitement des outils open source similaires (par exemple, Pentaho , BIRT , etc.), mais l'intégration a tendance à être meilleure avec SQL Server.
Cela dit, il existe des inconvénients importants, qui peuvent ou non être des facteurs décisifs pour vous :
- vous êtes bloqué avec les serveurs Windows, avec tous les avantages et les inconvénients que cela implique
- SQL Server, en particulier les éditions haut de gamme, sont coûteux ! Pour les petites bases de données (<4 Go, je pense), SQL Server Express est gratuit, cependant, et est presque aussi complet que le serveur SQL standard - si vous savez que vos données vont être petites et que vous savez que votre patron est un radin , Express est la voie à suivre. En outre, il existe une nouvelle édition Web de SQL Server 2008 qui, pour les applications Web accessibles sur Internet, devrait théoriquement offrir un hébergement bon marché puisque le coût pour un hébergeur n'est que de 15 $/mois par processeur.
- Ce n'est pas open source. Certaines entreprises et équipes de développement sont très passionnées par cela, pour de bonnes raisons (débogage, coût, philosophie, etc.) !
- lié à ce qui précède :si vous souhaitez corriger un bogue dans MySQL et que vous avez les compétences nécessaires, vous pouvez le réparer vous-même. Avec SQL Server, il y a des bugs douloureux dans le traitement des requêtes, l'optimisation, etc. qui persistent pendant des années. J'ai passé un temps absurde à contourner certains d'entre eux.
- pour les charges de travail très simples, en lecture seule (ou non transactionnelles) (par exemple, un accès au cache basé sur une base de données à partir d'une application Web) où vous pouvez vous en sortir en utilisant MyISAM au lieu d'InnoDB, j'entends dire que MySQL peut être beaucoup plus rapide .
Mise en garde :J'entends dire que MySQL 6.0 est censé combler bon nombre des lacunes et des différences ci-dessus, mais je ne me suis certes pas tenu au courant de la façon dont Oracle, etc. affectera le calendrier et/ou l'ensemble de fonctionnalités.
re :votre "C # est intégré" note :oui, vous pouvez développer des procédures stockées, des fonctions, des agrégats, etc. en utilisant les langages .NET, mais à mon humble avis, dans la plupart des scénarios, cela pose plus de problèmes qu'il n'en vaut la peine, notamment parce que le déploiement est plus difficile et Les DBA sont moins à l'aise avec le code .NET sur leurs serveurs. La vraie victoire pour une combinaison C # + .NET + Visual Studio + SQL Server, à mon humble avis, est qu'ils ont été conçus en parallèle au cours des 10 dernières années pour bien fonctionner ensemble, vous obtiendrez donc une facilité d'utilisation et une synergie que vous peut ne pas utiliser MySQL. Cela dit, comme je l'ai noté ci-dessus, ce n'est pas un deal-breaker ou un deal-maker... c'est juste plus fluide en utilisant SQL Server avec le reste de la pile Microsoft.
En résumé, permettez-moi de préciser que, pour de nombreuses charges de travail de base de données, MySQL est assez bon :il fonctionne, il est stable, il est rapide, il dispose d'outils raisonnablement bons, etc. Et il est abordable ! :-) Je ne refuserais jamais un projet simplement parce qu'ils utilisent MySQL. Mais la comparaison est comme conduire une Honda contre une BMW... la Honda vous emmène là où vous voulez aller, mais si votre portefeuille peut le supporter, vous apprécierez beaucoup plus la conduite avec le Bimmer. :-)
