Diferencias entre MySQL y SQL Server [cerrado]

Soy un desarrollador de ASP.NET que ha utilizado Microsoft SQL Serverpara todas mis necesidades de bases de datos (tanto en el trabajo como para proyectos personales).

Estoy considerando probar la pila LAMP para algunos de mis proyectos personales.

¿Cuáles son algunas de las principales diferencias entre MySQLy SQL Server? ¿Es el uso de procedimientos almacenados una práctica común en MySQL?

¿Algún consejo o recurso que me recomendarías para ayudarme con el cambio?

Para aquellos que tienen experiencia con ambos, ¿faltan características MySQL?

Una cosa que debe tener en cuenta son las diferencias bastante graves en la forma en que SQL Server y MySQL implementan la sintaxis de SQL.

Aquí hay una buena comparación de diferentes implementaciones de SQL .

Por ejemplo, eche un vistazo a la sección top-n. En MySQL:

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

En SQL Server (T-SQL):

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

Muchos comentarios aquí parecen más argumentos religiosos que declaraciones de la vida real. He trabajado durante años con MySQL y MSSQL y ambos son buenos productos. Elegiría MySQL principalmente en función del entorno en el que esté trabajando. La mayoría de los proyectos de código abierto usan MySQL, así que si vas en esa dirección, MySQL es tu elección. Si desarrolla algo con .Net, elegiría MSSQL, no porque sea mucho mejor, sino porque eso es lo que la mayoría de la gente usa. Actualmente estoy en un proyecto que usa ASP.NET con MySQL y C #. Funciona perfectamente bien.

No puedo creer que nadie haya mencionado que MySQL no admite expresiones de tabla común (CTE) / "con" declaraciones. Es una diferencia bastante molesta.

Es más probable que MySQL tenga problemas de corrupción de la base de datos, y no los soluciona automáticamente cuando ocurren. He trabajado con MSSQL desde la versión 6.5 y no recuerdo un problema de corrupción de la base de datos que desconectó la base de datos. Las pocas veces que trabajé con MySQL en un entorno de producción, un problema de corrupción de la base de datos desconectó toda la base de datos hasta que ejecutamos la cosa mágica "arregla mi índice dañado" desde la línea de comandos.

El sistema de registro y transacciones de MSSQL, en mi experiencia, maneja casi cualquier cosa, incluido un ciclo de energía o falla de hardware, sin corrupción de la base de datos, y si algo se estropea, lo arregla automáticamente.

Esta ha sido mi experiencia, y me alegraría saber que esto se ha solucionado o que estábamos haciendo algo 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

Francamente, no puedo encontrar una sola razón para usar MySQL en lugar de MSSQL. El problema antes era el costo, pero SQL Server 2005 Express es gratuito y hay muchas empresas de alojamiento web que ofrecen alojamiento completo con servidor sql por menos de $ 5.00 al mes.

MSSQL es más fácil de usar y tiene muchas características que no existen en MySQL.

Todo en MySQL parece estar más cerca del metal que en MSSQL, y la documentación lo trata de esa manera. Especialmente para la optimización, deberá comprender cómo interactúan los índices, la configuración del sistema y el optimizador en diversas circunstancias.

El "optimizador" es más un analizador sintáctico. En MSSQL, su plan de consultas suele ser una sorpresa (generalmente bueno, a veces no). En MySQL, hace más o menos lo que le pediste que hiciera, como esperabas. Lo que significa que usted mismo necesita tener una comprensión profunda de las diversas formas en que se puede hacer.

No se basa en un buen modelo de TRANSACCIÓN (motor MyISAM predeterminado).

La configuración del sistema de archivos es su problema.

Toda la configuración de la base de datos es su problema, especialmente varios tamaños de caché.

A veces parece mejor pensarlo como un isam glorificado ad-hoc. Codd y Date no tienen mucho peso aquí. Lo dirían sin vergüenza.

Creo que una de las principales cosas a tener en cuenta es que las versiones anteriores a MySQL 5.0 no tenían vistas, desencadenantes y procedimientos almacenados.

Más de esto se explica en la página de descarga de MySQL 5.0 .

@abdu

Lo principal que he encontrado que MySQL tiene sobre MSSQL es el soporte de zona horaria: la capacidad de cambiar agradablemente entre zonas horarias, respetando el horario de verano es fantástico.

Compara esto:

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

a las contorsiones involucradas en esta respuesta .

En cuanto al comentario "más fácil de usar", diría que el punto es que son diferentes, y si conoce uno, habrá una sobrecarga en el aprendizaje del otro.

Ambos son el servidor Product Sql de DBMS es una aplicación comercial, mientras que MySql es una aplicación de apertura. Ambos productos incluyen una función similar, sin embargo, el servidor sql debe usarse para una solución empresarial, mientras que mysql podría adaptarse a una implementación más pequeña. replicación, seguridad granalar y significativa, necesita un servidor sql

MySql ocupa menos espacios en el disco y usa menos memoria y CPU que el servidor SQL

¿Alguien tiene alguna buena experiencia con un "puerto" de una base de datos desde SQL Server a MySQL?

¡Esto debería ser bastante doloroso! Cambié las versiones de MySQL de 4.xa 5.xy varias declaraciones ya no funcionarían como solían hacerlo. El analizador de consultas se "mejoró", por lo que las declaraciones que anteriormente estaban ajustadas para el rendimiento ya no funcionarían como se esperaba.

La lección aprendida al trabajar con una base de datos MySQL de 500 GB: ¡es un tema sutil y cualquier otra cosa menos trivial!

@Cebjyre. El IDE si Enterprise Manager o Management Studio es mejor que cualquier cosa que haya visto hasta ahora para MySQL. Digo 'más fácil de usar' porque puedo hacer muchas cosas en MSSQL donde MySQL no tiene contrapartes. En MySQL no tengo idea de cómo ajustar las consultas simplemente mirando el plan de consulta o las estadísticas. El asistente de ajuste de índice en MSSQL toma la mayor parte de las conjeturas sobre qué índices faltan o están fuera de lugar.

Una deficiencia de MySQL es que no hay un tamaño máximo para una base de datos. La base de datos solo aumentaría de tamaño hasta que llene el disco. Imagine si este disco comparte bases de datos con otros usuarios y de repente todas sus consultas fallan porque sus bases de datos no pueden crecer. He informado de este problema a MySQL hace mucho tiempo. No creo que esté arreglado todavía.

Al pasar algún tiempo trabajando con MySQL desde el punto de vista de sintaxis de MSSQL a MySQL, me encontré limitado en lo que podía hacer.

Hay límites bizarros para actualizar una tabla mientras se hace referencia a la misma tabla durante una actualización.

Además, ACTUALIZAR DESDE no funciona y la última vez que verifiqué tampoco admiten la sintaxis Oracle MERGE INTO. Este fue un espectáculo para mí y dejé de pensar que llegaría a cualquier lugar con MySQL después de eso.