Unterschiede zwischen MySQL und SQL Server [geschlossen]

Ich bin ein ASP.NET- Entwickler, der Microsoft SQL Serveralle meine Datenbankanforderungen (sowohl bei der Arbeit als auch für persönliche Projekte) erfüllt hat.

Ich denke darüber nach, den LAMP- Stack für einige meiner persönlichen Projekte auszuprobieren.

Was sind einige der Hauptunterschiede zwischen MySQLund SQL Server? Ist die Verwendung gespeicherter Prozeduren eine gängige Praxis MySQL?

Irgendwelche Ratschläge oder Ressourcen, die Sie empfehlen würden, um mir beim Wechsel zu helfen?

Gibt es für diejenigen, die Erfahrung mit beiden haben, fehlende Funktionen von MySQL?

Eine Sache, auf die Sie achten müssen, sind die ziemlich gravierenden Unterschiede in der Art und Weise, wie SQL Server und MySQL die SQL-Syntax implementieren.

Hier ist ein schöner Vergleich verschiedener SQL-Implementierungen .

Schauen Sie sich zum Beispiel den Abschnitt oben-n an. In MySQL:

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

In SQL Server (T-SQL):

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

Viele Kommentare hier klingen eher nach religiösen Argumenten als nach Aussagen aus dem wirklichen Leben. Ich habe jahrelang sowohl mit MySQL als auch mit MSSQL gearbeitet und beide sind gute Produkte. Ich würde MySQL hauptsächlich basierend auf der Umgebung wählen, an der Sie arbeiten. Die meisten Open Source-Projekte verwenden MySQL. Wenn Sie also in diese Richtung gehen, ist MySQL Ihre Wahl. Wenn Sie etwas mit .Net entwickeln, würde ich MSSQL wählen, nicht weil es viel besser ist, sondern nur, weil die meisten Leute dies verwenden. Ich bin derzeit in einem Projekt, das ASP.NET mit MySQL und C # verwendet. Es funktioniert einwandfrei.

Ich kann nicht glauben, dass niemand erwähnt hat, dass MySQL Common Table Expressions (CTE) / "with" -Anweisungen nicht unterstützt. Es ist ein ziemlich nerviger Unterschied.

MySQL hat mit größerer Wahrscheinlichkeit Probleme mit der Datenbankbeschädigung und behebt diese nicht automatisch, wenn sie auftreten. Ich habe seit Version 6.5 mit MSSQL gearbeitet und kann mich nicht an ein Datenbankbeschädigungsproblem erinnern, bei dem die Datenbank offline geschaltet wurde. Die wenigen Male, die ich mit MySQL in einer Produktionsumgebung gearbeitet habe, hat ein Datenbankbeschädigungsproblem die gesamte Datenbank offline geschaltet, bis wir die magische Funktion "Bitte beheben Sie meinen beschädigten Index" über die Befehlszeile ausgeführt haben.

Das Transaktions- und Journaling-System von MSSQL verarbeitet meiner Erfahrung nach fast alles - einschließlich eines Aus- und Wiedereinschaltvorgangs oder eines Hardwarefehlers - ohne Beschädigung der Datenbank. Wenn etwas durcheinander kommt, wird es automatisch behoben.

Dies war meine Erfahrung und ich würde mich freuen zu hören, dass dies behoben wurde oder wir etwas falsch gemacht haben.

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

Ehrlich gesagt kann ich keinen einzigen Grund finden, MySQL anstelle von MSSQL zu verwenden. Früher war das Problem kostenpflichtig, aber SQL Server 2005 Express ist kostenlos und es gibt viele Webhosting-Unternehmen, die vollständiges Hosting mit SQL Server für weniger als 5,00 USD pro Monat anbieten.

MSSQL ist einfacher zu verwenden und verfügt über viele Funktionen, die in MySQL nicht vorhanden sind.

Alles in MySQL scheint näher am Metall zu sein als in MSSQL, und die Dokumentation behandelt es so. Insbesondere für die Optimierung müssen Sie verstehen, wie Indizes, Systemkonfiguration und das Optimierungsprogramm unter verschiedenen Umständen interagieren.

Der "Optimierer" ist eher ein Parser. In MSSQL ist Ihr Abfrageplan oft eine Überraschung (normalerweise gut, manchmal nicht). In MySQL macht es so ziemlich das, was Sie von ihm verlangt haben, so wie Sie es erwartet haben. Das bedeutet, dass Sie selbst ein tiefes Verständnis für die verschiedenen Möglichkeiten haben müssen.

Nicht um ein gutes TRANSACTION-Modell herum aufgebaut (Standard-MyISAM-Engine).

Die Einrichtung des Dateisystems ist Ihr Problem.

Die gesamte Datenbankkonfiguration ist Ihr Problem - insbesondere verschiedene Cache-Größen.

Manchmal scheint es am besten, es als einen ad-hoc verherrlichten Isam zu betrachten. Codd und Date haben hier nicht viel Gewicht. Sie würden es ohne Verlegenheit sagen.

Ich denke, eines der wichtigsten Dinge, auf die Sie achten sollten, ist, dass Versionen vor MySQL 5.0 keine Ansichten, Trigger und gespeicherten Prozeduren hatten.

Weitere Informationen hierzu finden Sie auf der MySQL 5.0-Download-Seite .

@abdu

Die Hauptsache, die MySQL gegenüber MSSQL hat, ist die Zeitzonenunterstützung - die Möglichkeit, zwischen Zeitzonen zu wechseln und dabei die Sommerzeit zu berücksichtigen, ist fantastisch.

Vergleichen Sie dies:

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                                             |
+-----------------------------------------------------------------+

zu den Verrenkungen bei dieser Antwort .

Was den "einfacher zu verwendenden" Kommentar betrifft, würde ich sagen, dass der Punkt darin besteht, dass sie unterschiedlich sind, und wenn Sie einen kennen, wird es einen Aufwand bedeuten, den anderen zu lernen.

Bei beiden handelt es sich bei dem Produkt-SQL-Server von DBMS um eine kommerzielle Anwendung, während MySQL eine OpenSouces-Anwendung ist. Beide Produkte enthalten ähnliche Funktionen. Der SQL-Server sollte jedoch für eine Unternehmenslösung verwendet werden, während MySQL möglicherweise für eine kleinere Implementierung geeignet ist. Replikation, granalare Sicherheit und signifikante, benötigen Sie SQL Server

MySQL nimmt weniger Speicherplatz auf der Festplatte ein und benötigt weniger Speicher und CPU als SQL Server

Hat jemand gute Erfahrungen mit einem "Port" einer Datenbank von SQL Server zu MySQL?

Das sollte ziemlich schmerzhaft sein! Ich habe die Versionen von MySQL von 4.x auf 5.x umgestellt und verschiedene Anweisungen würden nicht mehr so ​​funktionieren wie früher. Der Abfrageanalysator wurde "verbessert", sodass zuvor auf Leistung abgestimmte Anweisungen nicht mehr wie erwartet funktionieren.

Die Lektion aus der Arbeit mit einer 500-GB-MySQL-Datenbank: Es ist ein subtiles Thema und alles andere als trivial!

@ Cejjyre. Die IDE, ob Enterprise Manager oder Management Studio, ist besser als alles, was ich bisher für MySQL gesehen habe. Ich sage "einfacher zu bedienen", weil ich viele Dinge in MSSQL tun kann, wo MySQL keine Gegenstücke hat. In MySQL habe ich keine Ahnung, wie ich die Abfragen optimieren soll, indem ich einfach den Abfrageplan oder die Statistiken betrachte. Der Indexoptimierungsassistent in MSSQL übernimmt den größten Teil der Rätselraten darüber, welche Indizes fehlen oder verlegt sind.

Ein Nachteil von MySQL ist, dass es keine maximale Größe für eine Datenbank gibt. Die Datenbank würde nur größer werden, bis die Festplatte voll ist. Stellen Sie sich vor, diese Festplatte teilt Datenbanken mit anderen Benutzern und plötzlich schlagen alle Abfragen fehl, weil ihre Datenbanken nicht wachsen können. Ich habe dieses Problem vor langer Zeit MySQL gemeldet. Ich denke, es ist noch nicht behoben.

Während ich einige Zeit mit MySQL von der MSSQL- bis zur MySQL-Syntax POV arbeitete, war ich immer wieder in meinen Möglichkeiten eingeschränkt.

Es gibt bizzare Grenzen für das Aktualisieren einer Tabelle, während dieselbe Tabelle während eines Updates aktualisiert wird.

Außerdem funktioniert UPDATE FROM nicht und als ich das letzte Mal überprüft habe, unterstützen sie auch nicht die Oracle MERGE INTO-Syntax. Dies war ein Show Stopper für mich und ich hörte auf zu denken, dass ich danach mit MySQL irgendwohin kommen würde.