Różnice między MySQL i SQL Server [zamknięte]

Jestem programistą ASP.NET, który wykorzystywał Microsoft SQL Serverwszystkie moje potrzeby związane z bazami danych (zarówno w pracy, jak i przy projektach osobistych).

Rozważam wypróbowanie stosu LAMP do niektórych moich osobistych projektów.

Jakie są główne różnice między MySQLi SQL Server? Czy używanie procedur składowanych jest powszechną praktyką w programie MySQL?

Jakieś rady lub zasoby, które poleciłbyś mi przy zmianie?

Czy dla tych, którzy mają doświadczenie w obu przypadkach, brakuje jakichś funkcji MySQL?

Jedną rzeczą, na którą musisz zwrócić uwagę, są dość poważne różnice w sposobie implementacji składni SQL przez SQL Server i MySQL.

Oto ładne porównanie różnych implementacji SQL .

Na przykład spójrz na sekcję u góry n. W MySQL:

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

W programie SQL Server (T-SQL):

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

Wiele komentarzy brzmi bardziej jak argumenty religijne niż stwierdzenia z życia wzięte. Pracowałem od lat z MySQL i MSSQL i oba są dobrymi produktami. MySQL wybrałbym głównie w oparciu o środowisko, na którym pracujesz. Większość projektów open source używa MySQL, więc jeśli pójdziesz w tym kierunku, MySQL jest twoim wyborem. Jeśli tworzysz coś z .Net, wybrałbym MSSQL nie dlatego, że jest dużo lepszy, ale dlatego, że właśnie tego używa większość ludzi. Obecnie jestem w projekcie, który używa ASP.NET z MySQL i C #. Działa doskonale.

Nie mogę uwierzyć, że nikt nie wspomniał, że MySQL nie obsługuje instrukcji Common Table Expressions (CTE) / „with”. To dość denerwująca różnica.

MySQL częściej ma problemy z uszkodzeniem bazy danych i nie naprawia ich automatycznie, gdy się pojawią. Pracowałem z MSSQL od wersji 6.5 i nie pamiętam problemu z uszkodzeniem bazy danych, powodując przejście do trybu offline. Kilka razy, kiedy pracowałem z MySQL w środowisku produkcyjnym, problem z uszkodzeniem bazy danych spowodował, że cała baza danych stała się offline, dopóki nie uruchomiliśmy magicznego polecenia „proszę naprawić uszkodzony indeks” z wiersza poleceń.

Z mojego doświadczenia wynika, że ​​system transakcji i kronikowania MSSQL obsługuje prawie wszystko - w tym cykl zasilania lub awarię sprzętu - bez uszkodzenia bazy danych, a jeśli coś się zepsuje, naprawia to automatycznie.

Takie było moje doświadczenie i byłbym szczęśliwy, słysząc, że zostało to naprawione lub zrobiliśmy coś nie tak.

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

Szczerze mówiąc, nie mogę znaleźć ani jednego powodu, by używać MySQL zamiast MSSQL. Wcześniej problem był kosztowny, ale SQL Server 2005 Express jest darmowy i istnieje wiele firm hostingowych, które oferują pełny hosting z serwerem sql za mniej niż 5,00 $ miesięcznie.

MSSQL jest łatwiejszy w użyciu i ma wiele funkcji, których nie ma w MySQL.

Wszystko w MySQL wydaje się być zrobione bliżej metalu niż w MSSQL, a dokumentacja traktuje to w ten sposób. Szczególnie w przypadku optymalizacji musisz zrozumieć, w jaki sposób indeksy, konfiguracja systemu i optymalizator współdziałają w różnych okolicznościach.

„Optymalizator” to bardziej parser. W MSSQL twój plan zapytań jest często niespodzianką (zwykle dobry, czasem nie). W MySQL robi właściwie to, o co go prosiłeś, tak, jak tego oczekiwałeś. Co oznacza, że ​​sam musisz dobrze zrozumieć różne sposoby, w jakie można to zrobić.

Nie zbudowany wokół dobrego modelu TRANSACTION (domyślny silnik MyISAM).

Twoim problemem jest konfiguracja systemu plików.

Cała konfiguracja bazy danych jest Twoim problemem - szczególnie różne rozmiary pamięci podręcznej.

Czasami wydaje się, że najlepiej jest myśleć o tym jako o ad-hoc, gloryfikowanym isamie. Codd i Date nie mają tu zbytniej wagi. Powiedzieliby to bez zażenowania.

Myślę, że jedną z głównych rzeczy, na które należy zwrócić uwagę, jest to, że wersje wcześniejsze niż MySQL 5.0 nie miały widoków, wyzwalaczy i procedur składowanych.

Więcej informacji na ten temat można znaleźć na stronie pobierania MySQL 5.0 .

@abdu

Najważniejszą rzeczą, jaką odkryłem, że MySQL ma ponad MSSQL, jest obsługa stref czasowych - możliwość ładnego przełączania się między strefami czasowymi, z poszanowaniem czasu letniego, jest fantastyczna.

Porównaj to:

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

na skrzywienie związane z tą odpowiedzią .

Jeśli chodzi o komentarz „łatwiejszy w użyciu”, powiedziałbym, że chodzi o to, że są one różne, a jeśli znasz jeden, nauka drugiego będzie kosztować.

Oba to serwer DBMS Product Sql jest aplikacją komercyjną, podczas gdy MySql jest aplikacją opensouces Oba produkty mają podobną funkcję, jednak serwer sql powinien być używany dla rozwiązania korporacyjnego, podczas gdy mysql może pasować do mniejszych wdrożeń. Jeśli potrzebujesz funkcji takiej jak odzyskiwanie, replikacja, bezpieczeństwo granalar i istotne, potrzebujesz serwera sql

MySql zajmuje mniej miejsca na dysku oraz zużywa mniej pamięci i procesora niż serwer sql

Czy ktoś ma dobre doświadczenia z „portem” bazy danych z SQL Server do MySQL?

To powinno być dość bolesne! Zmieniłem wersje MySQL z 4.x na 5.x i różne instrukcje nie działały już tak, jak kiedyś. Analizator zapytań został „ulepszony”, więc instrukcje, które wcześniej były dostrojone pod kątem wydajności, nie będą już działać zgodnie z oczekiwaniami.

Lekcja wyciągnięta z pracy z bazą danych MySQL o pojemności 500 GB: to subtelny temat i wszystko inne, ale trywialne!

@Cebjyre. IDE, czy Enterprise Manager czy Management Studio, jest lepsze niż wszystko, co do tej pory widziałem dla MySQL. Mówię „łatwiejszy w użyciu”, ponieważ mogę zrobić wiele rzeczy w MSSQL, gdzie MySQL nie ma odpowiedników. W MySQL nie mam pojęcia, jak dostroić zapytania, po prostu patrząc na plan zapytań lub patrząc na statystyki. Kreator dostrajania indeksów w MSSQL zajmuje się większością zgadywania, których indeksów brakuje lub które są niewłaściwie umieszczone.

Jedną z wad MySQL jest brak maksymalnego rozmiaru bazy danych. Baza danych po prostu powiększyłaby się, aż zapełniłaby dysk. Wyobraź sobie, że ten dysk udostępnia bazy danych innym użytkownikom i nagle wszystkie ich zapytania kończą się niepowodzeniem, ponieważ ich bazy danych nie mogą się rozwijać. Zgłosiłem ten problem do MySQL dawno temu. Nie sądzę, że to jeszcze naprawione.

Poświęcając trochę czasu na pracę z MySQL, od MSSQL do składni MySQL POV. Wciąż byłem ograniczony w tym, co mogłem zrobić.

Istnieją dziwaczne ograniczenia dotyczące aktualizacji tabeli podczas odnawiania tej samej tabeli podczas aktualizacji.

Dodatkowo UPDATE FROM nie działa i kiedy ostatnio sprawdzałem, nie obsługują również składni Oracle MERGE INTO. To było dla mnie zatrzymanie pokazu i przestałem myśleć, że później osiągnę coś z MySQL.