Pułapki związane z używaniem MySQL jako bazy danych? [Zamknięte]

Wielokrotnie czytałem online, że MySQL to zła baza danych. Miejsca, które przeczytałem, zawierają wątki na Reddit, ale nigdy nie zastanawiają się, dlaczego jest to kiepski produkt.

Czy istnieje jakaś prawda w tym twierdzeniu? Nigdy nie użyłem go poza bardzo prostym scenariuszem CRUD, i to było na projekt uniwersytecki na drugim roku.

Jakie ewentualne pułapki występują przy wyborze MySQL jako bazy danych?

Istnieją dwa rodzaje pułapek: korzystanie z MySQL jako smaku RDBMS i korzystanie z RDBMS zamiast innych typów baz danych.

Używanie MySQL zamiast alternatywnych RDBMS:

• Zobacz tabelę porównawczą wikipedii dla różnych porównań MySQL z innymi RDBMS.
• Prawdopodobnie wolisz Microsoft SQL Server, jeśli budujesz aplikację internetową ASP.NET, ponieważ system został zaprojektowany tak, aby dobrze ze sobą współpracować, uważam, że zarówno dla programistów, jak i kierowników IT
• Możesz preferować Oracle, jeśli potrzebujesz bardziej zaawansowanej konfiguracji DB obejmującej klastrowanie (Oracle RAC) lub zaawansowane procedury DB. Nie to, że MySQL nie obsługuje wielu funkcji, ale z tego, co widziałem, znacznie bardziej prawdopodobne jest, że znajdziesz doświadczonego DBA, który zna te rzeczy dla Oracle niż MySQL.
• Zobacz to pytanie w SO, aby uzyskać szczegółowe porównania PostgreSQL do MySQL, które mówią, że jest to lepsze niż ja.
• Jeszcze więcej SO: Wady mysql w porównaniu z innymi bazami danych

Używanie RDBMS zamiast innych typów:

• Przeczytaj o „NoSQL” i innych typach DB:
  • NoSQL: Gdyby to było takie proste
  • (powyższe jest powiązane z) Kiedy używać MongoDB lub innych systemów baz danych zorientowanych na dokumenty? ( więcej )
  • /software/5354/are-nosql-databases-going-to-take-the-place-of-relational-databases-is-sql-going
  • Kiedy stosować CouchDB vs RDBMS
• RDBMS często korzystają z indeksowania w celu zwiększenia wydajności. W bardzo dużych bazach danych może to mieć negatywny wpływ na wydajność, a nawet zmniejszyć optymalną liczbę wierszy na DB / Odłamek wymagającą więcej sprzętu
• Nie tak idealne, jeśli przechowujesz ogromną ilość danych, ale odczytujesz rzadziej
• Jeśli nie masz wielu relacji zagranicznych, relacyjne bazy danych mogą nie być idealne (przechowywanie dokumentów)

Biorąc to wszystko pod uwagę, MySQL jest świetną bazą danych i przez ostatnie 8 lat nie pracowałem w firmie, która z niej nie korzystała, w wielu różnych aplikacjach internetowych (takich jak e-commerce, strony internetowe / aplikacje , przedsiębiorstwa / B2B, gry internetowe). W przypadku większości typowych przypadków użycia aplikacji internetowych jest to świetny wybór.

MySQL jest teraz kontrolowany przez Oracle - chociaż open source wciąż decyduje o kierunku projektu i tym, co się dzieje.

Jeśli chodzi o bycie złą bazą danych, nie jest to po prostu „prostsze” niż niektóre inne.

Jeśli szukasz słabości, wskażę je za Ciebie, weźmy na przykład PostgreSQL.

1. MySQL nie ma typów i tablic kontenerów.
2. MySQL nie ma prawdziwych sekwencji (używają automatycznego przyrostu) - Sekwencje Postgres pozwalają wielu tabelom korzystać z jednej sekwencji, dzięki czemu możesz zagwarantować liczność w wielu tabelach.
3. Postgres jest zgodny z ACID, MySQL jest częściowo zgodny.
4. Postgres implementuje zróżnicowanie znaków i tekst w ten sam sposób (Tabele Toast) - to podejście, które zdaniem większości jest lepsze niż MySQL.
5. Postgres ma tylko jeden backend pamięci - oznacza to, że masz zagwarantowane takie same funkcje wszędzie.
6. Postgres pozwala na funkcje po stronie serwera napisane w TCL, Python, R i Perl.
7. Postgres ma dobre wsparcie dla sterowników asynchronicznych w Pythonie - myślę, że jest to trochę trafione w MySQL

Historycznie słabo obsługiwał transakcje, a transakcje są ważne, jeśli trzeba zachować spójną bazę danych. Obecnie wielkim rapem jest to, że Oracle jest jego właścicielem.

Przez długi czas MySQL był bardziej „zabawkową” bazą danych. Nie obsługiwał zagnieżdżonych podselekcji, nie obsługiwał partycjonowania danych, nie oferował wielu poziomów izolacji transakcji, nie obsługiwał wyzwalaczy ani procedur przechowywanych - wiele innych rzeczy. Wiele osób pochodzących z Oracle lub SQL Server odrzuciło to.

Myślę, że prawdziwym powodem, dla którego nie widzisz wielu list wad MySQL, jest to, że ma dość wściekłą grupę fanów, którzy usuwają lub odrzucają jakiekolwiek publiczne wzmianki o nich. Wiem, że za każdym razem, gdy wspominałem o jakichkolwiek problemach, odpowiedzi były przeważnie negatywne.

MySQL jest zgodny z ACID, gdy jest używany z silnikiem pamięci InnoDB - nie ma powodu, aby tego nie robić MySQL jest zgodny z ACID (od wersji 5.5 InnoDB jest domyślnym silnikiem pamięci).

MySQL dostaje dużo złej prasy, ponieważ jest często używany (lub był do czasu pojawienia się NoSQL) jako wybór RDBMS przez ludzi, którzy prawie nie potrzebowali bazy danych (i być może mieli ograniczone umiejętności RDBMS) i dlatego używali jej raczej niezgrabnie sposób.

Często korzystałem z MySQL, a odkąd pojawił się 5.x, nie ma na co narzekać w 95% instalacji, które mają średnie wymagania drogowe.

Uszkodzenie danych: http://planet.mysql.com/entry/?id=16232

Pochodzi z 2008 roku. Miejmy nadzieję, że w międzyczasie wszystko się zmieniło.