Подводные камни использования MySQL в качестве базы данных? [закрыто]

Я неоднократно читал в Интернете, что MySQL - плохая база данных. В местах, которые я читал, есть некоторые темы в Reddit, но они, кажется, никогда не вникают в то, почему это плохой продукт.

Есть ли правда в этом утверждении? Я никогда не использовал его за очень простым сценарием CRUD, и это было для университетского проекта на втором курсе.

Какие подводные камни, если таковые имеются, при выборе MySQL в качестве базы данных?

Существует два вида ловушек: использование MySQL в качестве разновидности RDBMS и использование RDBMS вместо других типов баз данных.

Использование MySQL вместо альтернативных СУБД:

• См. Эту таблицу сравнения Википедии для различных сравнений MySQL с другими СУБД.
• Скорее всего, вы предпочтете Microsoft SQL Server, если вы создаете веб-приложение ASP.NET, так как система спроектирована так, чтобы хорошо работать вместе, я полагаю, как для разработчиков, так и для ИТ-менеджеров.
• Вы можете предпочесть Oracle, если вам нужна более сложная настройка БД, включающая кластеризацию (Oracle RAC) или расширенные процедуры БД. Не то, чтобы MySQL не поддерживал многие функции, но из того, что я видел, вы с большей вероятностью найдете опытного администратора баз данных, который знает это для Oracle, чем MySQL.
• См. Этот вопрос в SO для подробных сравнений PostgreSQL с MySQL, которые говорят это лучше, чем я.
• Еще больше SO: недостатки MySQL по сравнению с другими базами данных

Использование СУБД вместо других типов:

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

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

MySQL теперь находится под контролем Oracle - хотя с открытым исходным кодом они все еще определяют направление проекта и что входит в него.

С точки зрения плохой базы данных, нет, это просто «проще», чем некоторые другие.

Если вы ищете слабые места, я укажу на них, например, на PostgreSQL.

1. В MySQL отсутствуют типы контейнеров и массивы.
2. В MySQL отсутствуют истинные последовательности (они используют автоинкремент) - последовательности Postgres позволяют нескольким таблицам использовать одну последовательность, поэтому вы можете гарантировать количество элементов в нескольких таблицах.
3. Postgres совместим с ACID, MySQL частично совместим.
4. Postgres реализует изменение символов и текста одним и тем же способом (таблицы Toast) - такой подход, как многие считают, лучше, чем 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) и поэтому использовали ее довольно неуклюже. манера.

Я много использовал MySQL, и с тех пор, как вышел 5.x, на 95% установок, которые предъявляют средние требования к дороге, очень мало на это жаловаться.

Повреждение данных: http://planet.mysql.com/entry/?id=16232

Это с 2008 года. Будем надеяться, что за это время все изменилось.