Différences entre MySQL et SQL Server [fermé]

Question

je suis un ASP.NET développeur qui a utilisé Microsoft SQL Server pour tous mes besoins en bases de données (au travail et pour des projets personnels).

J'envisage d'essayer le LAMPE stack pour certains de mes projets personnels.

Quelles sont les principales différences entre MySQL et SQL Server?Utilise procédures stockées une pratique courante dans MySQL?

Avez-vous des conseils ou des ressources à recommander pour m'aider avec le changement ?

Pour ceux qui ont de l'expérience avec les deux, y a-t-il des fonctionnalités manquantes dans MySQL?

Answer 1

Une chose à laquelle vous devez faire attention est les différences assez importantes dans la manière dont SQL Server et MySQL implémentent la syntaxe SQL.

Voici un joli Comparaison de différentes implémentations SQL.

Par exemple, jetez un œil à la section top-n.Dans MySQL :

SELECT age
FROM person
ORDER BY age ASC
LIMIT 1 OFFSET 2

Dans SQL Server (T-SQL) :

SELECT TOP 3 WITH TIES *
FROM person
ORDER BY age ASC

Answer 2

De nombreux commentaires ici ressemblent plus à des arguments religieux qu’à des déclarations réelles.Je travaille depuis des années avec MySQL et MSSQL et les deux sont de bons produits.Je choisirais MySQL principalement en fonction de l'environnement sur lequel vous travaillez.La plupart des projets open source utilisent MySQL, donc si vous allez dans cette direction, MySQL est votre choix.Si vous développez quelque chose avec .Net, je choisirais MSSQL, non pas parce que c'est bien meilleur, mais simplement parce que c'est ce que la plupart des gens utilisent.Je suis actuellement sur un projet qui utilise ASP.NET avec MySQL et C#.Cela fonctionne parfaitement bien.

Answer 3

Je ne peux pas croire que personne n'ait mentionné que MySQL ne prend pas en charge les instructions Common Table Expressions (CTE) / "with".C'est une différence assez ennuyeuse.

Answer 4

MySQL est plus susceptible d'avoir des problèmes de corruption de base de données et ne les résout pas automatiquement lorsqu'ils se produisent.J'utilise MSSQL depuis la version 6.5 et je ne me souviens pas d'un problème de corruption de base de données mettant la base de données hors ligne.Les quelques fois où j'ai travaillé avec MySQL dans un environnement de production, un problème de corruption de base de données a mis toute la base de données hors ligne jusqu'à ce que nous exécutions la commande magique "Veuillez réparer mon index corrompu" à partir de la ligne de commande.

D'après mon expérience, le système de transactions et de journalisation MSSQL gère à peu près tout - y compris un cycle d'alimentation ou une panne matérielle - sans corruption de base de données, et si quelque chose est gâché, il le corrige automatiquement.

C'est mon expérience et je serais heureux d'apprendre que cela a été corrigé ou que nous avons fait quelque chose de mal.

http://dev.mysql.com/doc/refman/6.0/en/corrupted-myisam-tables.html

http://www.google.com/search?q=site%3Abugs.mysql.com+index+corruption

Answer 5

Franchement, je ne trouve pas une seule raison d'utiliser MySQL plutôt que MSSQL.Avant, le problème était le coût, mais SQL Server 2005 Express est gratuit et de nombreuses sociétés d'hébergement Web proposent un hébergement complet avec serveur SQL pour moins de 5,00 $ par mois.

MSSQL est plus facile à utiliser et possède de nombreuses fonctionnalités qui n'existent pas dans MySQL.

Answer 6

Tout dans MySQL semble être plus proche du métal que dans MSSQL, et la documentation le traite de cette façon.En particulier pour l'optimisation, vous devrez comprendre comment les index, la configuration du système et l'optimiseur interagissent dans diverses circonstances.

L'"optimiseur" est plutôt un analyseur.Dans MSSQL, votre plan de requête est souvent une surprise (généralement bonne, parfois non).Dans MySQL, il fait à peu près ce que vous lui avez demandé, comme vous l'espériez.Ce qui signifie que vous devez vous-même avoir une compréhension approfondie des différentes manières de procéder.

Non construit autour d'un bon modèle TRANSACTION (moteur MyISAM par défaut).

La configuration du système de fichiers est votre problème.

Toute la configuration de la base de données est votre problème - en particulier les différentes tailles de cache.

Parfois, il semble préférable de le considérer comme un isam ad hoc et glorifié.Codd et Date n'ont pas beaucoup de poids ici.Ils le diraient sans gêne.

Answer 7

Je pense que l'une des principales choses à surveiller est que les versions antérieures à MySQL 5.0 n'avaient pas de vues, de déclencheurs et de procédures stockées.

Plus de ceci est expliqué dans le Page de téléchargement de MySQL 5.0.

Answer 8

@abdu

La principale chose que j'ai trouvée chez MySQL par rapport à MSSQL est la prise en charge des fuseaux horaires - la possibilité de changer facilement de fuseau horaire, en respectant l'heure d'été, est fantastique.

Comparez ceci :

mysql> SELECT CONVERT_TZ('2008-04-01 12:00:00', 'UTC', 'America/Los_Angeles');
+-----------------------------------------------------------------+
| CONVERT_TZ('2008-04-01 12:00:00', 'UTC', 'America/Los_Angeles') |
+-----------------------------------------------------------------+
| 2008-04-01 05:00:00                                             |
+-----------------------------------------------------------------+

aux contorsions impliquées à cette réponse.

Quant au commentaire « plus facile à utiliser », je dirais que le fait est qu’ils sont différents, et si vous connaissez l’un, il y aura une surcharge pour apprendre l’autre.

Answer 9

Les deux sont le produit du SGBD. Le serveur SQL est une application commerciale tandis que MySql est une application open source. Les deux produits incluent des fonctionnalités similaires, mais le serveur SQL doit être utilisé pour une solution d'entreprise, tandis que MySQL peut convenir à une implémentation plus petite. Si vous avez besoin de fonctionnalités telles que la récupération, réplication, sécurité granulaire et importante, vous avez besoin d'un serveur SQL

MySql occupe moins d'espace sur le disque et utilise moins de mémoire et de processeur que le serveur SQL

Answer 10

Quelqu'un a une bonne expérience avec un "port" d'une base de données de SQL Server à MySQL?

Cela devrait être assez douloureux !J'ai changé les versions de MySQL de 4.x à 5.x et diverses instructions ne fonctionnaient plus comme avant.L'analyseur de requêtes a été "amélioré", de sorte que les instructions qui étaient auparavant optimisées pour les performances ne fonctionneraient plus comme prévu.

La leçon tirée de l'utilisation d'une base de données MySQL de 500 Go :C'est un sujet subtil et tout sauf trivial !

Answer 11

@Cebjyre.L'EDI, qu'il soit Enterprise Manager ou Management Studio, est meilleur que tout ce que j'ai vu jusqu'à présent pour MySQL.Je dis « plus facile à utiliser » parce que je peux faire beaucoup de choses dans MSSQL là où MySQL n'a pas d'équivalent.Dans MySQL, je ne sais pas comment ajuster les requêtes en regardant simplement le plan de requête ou en consultant les statistiques.L'assistant de réglage des index dans MSSQL prend en charge l'essentiel du travail de recherche sur les index manquants ou égarés.

L'un des inconvénients de MySQL est qu'il n'y a pas de taille maximale pour une base de données.La taille de la base de données augmenterait simplement jusqu'à ce qu'elle remplisse le disque.Imaginez si ce disque partage des bases de données avec d'autres utilisateurs et que soudainement toutes leurs requêtes échouent parce que leurs bases de données ne peuvent pas croître.J'ai signalé ce problème à MySQL il y a longtemps.Je ne pense pas que ce soit encore réglé.

Answer 12

En passant du temps à travailler avec MySQL, du point de vue de la syntaxe MSSQL à MySQL, je me suis retrouvé limité dans ce que je pouvais faire.

Il existe des limites bizarres à la mise à jour d'une table lors de la référence à la même table lors d'une mise à jour.

De plus, UPDATE FROM ne fonctionne pas et la dernière fois que j'ai vérifié, ils ne prennent pas non plus en charge la syntaxe Oracle MERGE INTO.Cela a été un obstacle pour moi et j'ai arrêté de penser que j'arriverais à quelque chose avec MySQL après cela.