Підводні камені використання MySQL як вибір вашої бази даних? [зачинено]

Я багато разів читав в Інтернеті, що MySQL - це погана база даних. Місця, які я читав, містять деякі теми на Reddit, але вони ніколи не заглиблюються в те, чому це поганий продукт.

Чи є правда до цього твердження? Я ніколи не використовував його поза дуже простим сценарієм CRUD, і це було для університетського проекту протягом мого другого курсу.

Які підводні камені, якщо такі є, вибирають MySQL як вашу базу даних?

Існує два різних види підводних каменів: ті, які використовують MySQL як ваш смак RDBMS, і використання RDBMS замість інших типів баз даних.

Використання MySQL замість альтернативних RDBMS:

• Дивіться цю таблицю порівняння wikipedia для різних порівнянь MySQL з іншими RDBMS.
• Ви, швидше за все, віддасте перевагу Microsoft SQL Server, якщо ви будуєте веб-додаток ASP.NET, оскільки система розроблена для того, щоб добре працювати разом, я вважаю, як для розробників, так і для ІТ-менеджерів
• Ви можете віддати перевагу Oracle, якщо вам потрібна більш досконала настройка БД, що включає кластеризацію (Oracle RAC) або розширені процедури БД. Не те, що MySQL не підтримує багато функцій, але з того, що я бачив, ви набагато більше шансів знайти досвідченого DBA, який знає цей матеріал для Oracle, ніж MySQL.
• Дивіться це запитання в SO для широких порівнянь PostgreSQL з MySQL, які говорять про це краще, ніж я можу.
• Ще більше SO: Недоліки mysql порівняно з іншими базами даних

Використання RDBMS замість інших типів:

• Прочитайте про ідею "NoSQL" та інших типів БД:
  • NoSQL: Якби це було так просто
  • (вище пов'язано з) Коли використовувати MongoDB або інші системи баз даних, орієнтовані на документи? ( більше )
  • /software/5354/are-nosql-databases-going-to-take-the-place-of-relational-databases-is-sql-going
  • Коли використовувати CouchDB проти RDBMS
• RDBMS широко використовують індексацію продуктивності. У дуже великих базах даних це може негативно вплинути на продуктивність або навіть зменшити оптимальну кількість рядків на DB / Shard, вимагаючи більше апаратного забезпечення
• Не так ідеально, якщо ви зберігаєте величезну кількість даних, але читаєте рідше
• Якщо у вас немає багато закордонних зв’язків, реляційні бази даних можуть бути не ідеальними (зберігання документів)

Все, що говорити, MySQL - це чудова база даних, і я не працював у компанії протягом останніх 8 років, яка не використовувала її, у широкому спектрі веб-додатків (таких як електронна комерція, веб-сайти / програми , підприємство / B2B, веб-ігри). Для більшості типових випадків використання веб-додатків це чудовий вибір.

MySQL зараз перебуває під контролем Oracle - хоча з відкритим кодом вони все ще визначають напрямок проекту та те, що потрапляє.

Що стосується поганої бази даних, ні, це просто "простіше", ніж деякі інші.

Якщо ви шукаєте слабкі місця, я зазначу їх для вас, давайте, наприклад, взяти PostgreSQL.

1. У MySQL відсутні типи контейнерів та масивів.
2. У MySQL бракує справжніх послідовностей (вони використовують автоматичне збільшення) - послідовності Postgres дозволяють багатьом таблицям використовувати одну послідовність, щоб ви могли гарантувати кардинальність у кількох таблицях.
3. Postgres сумісний з ACID, MySQL частково сумісний.
4. Postgres реалізує різні символи та текст у однаковому порядку (Toast Tables) - такий підхід, на думку більшості, є кращим, ніж MySQL.
5. У Postgres є лише один резервний пристрій для зберігання даних - це означає, що ви гарантовано матимете однакові функції скрізь.
6. Postgres дозволяє виконувати функції на сервері, написані на TCL, Python, R та Perl.
7. Postgres має гарну підтримку для асинхронних драйверів у Python - я думаю, що це трохи потрапило або пропустило MySQL

Історично вона мала слабку підтримку транзакцій, і транзакції важливі, якщо вам потрібно підтримувати послідовну базу даних. У наш час великим репом є те, що Oracle володіє ним.

Тривалий час MySQL був більше «іграшковою» базою даних. Він не обробляв вкладені підбірки, не підтримував розподіл даних, не пропонував кілька рівнів ізоляції транзакцій, не підтримував тригери та зберігає процедури - багато чого. Багато людей, що надходять із фонів Oracle або SQL Server, відхилили його.

Я думаю, що справжньою причиною того, що ви не бачите багатьох списків недоліків MySQL, є те, що у нього є досить шалена база шанувальників, які видаляють або спростовують будь-які публічні згадки про них. Я знаю, що коли б я згадав про якісь проблеми, які у мене виникли, відповіді, як правило, вкрай негативні.

MySQL сумісний з ACID при використанні з двигуном зберігання InnoDB - немає причин для того, щоб MySQL не відповідав ACID (станом на версії 5.5 InnoDB - це система зберігання за замовчуванням).

MySQL отримує багато поганої преси, тому що його часто використовують (або до появи NoSQL) як обраних RDBMS людьми, які ледь не потребували бази даних (і, можливо, мали обмежені навички RDBMS), і тому використовували її досить непомітно. манера.

Я багато використовував MySQL, і оскільки 5.x з'явився, дуже мало поскаржитися на це 95% установок, які мають середні вимоги дорожнього руху.

Пошкодження даних: http://planet.mysql.com/entry/?id=16232

Це з 2008 року. Будемо сподіватися, що справи тим часом змінилися.