Armadilhas do uso do MySQL como sua escolha de banco de dados? [fechadas]

Eu li online em várias ocasiões que o MySQL é um banco de dados ruim. Os lugares que eu li isso incluem alguns tópicos no Reddit, mas eles nunca parecem investigar por que é um produto ruim.

Existe alguma verdade nessa afirmação? Eu nunca o usei além de um cenário CRUD muito simples, e isso foi para um projeto universitário durante meu segundo ano.

Que armadilhas, se houver , existem ao escolher o MySQL como seu banco de dados?

Existem dois tipos diferentes de armadilhas, as que usam o MySQL como seu tipo de RDBMS e as que usam um RDBMS em vez de outros tipos de bancos de dados.

Usando o MySQL em vez de RDBMSs alternativos:

• Veja esta tabela de comparação da Wikipedia para várias comparações do MySQL com outros RDBMSs.
• Você provavelmente preferirá o Microsoft SQL Server se estiver criando um aplicativo Web ASP.NET, pois o sistema foi projetado para funcionar bem em conjunto, acredito que tanto para desenvolvedores quanto para gerentes de TI
• Você pode preferir o Oracle se precisar de uma configuração de banco de dados mais avançada envolvendo clustering (Oracle RAC) ou procedimentos avançados de banco de dados. Não que o MySQL não suporte muitos dos recursos, mas pelo que vi, é muito mais provável que você encontre um DBA experiente que conheça essas coisas para Oracle do que o MySQL.
• Veja esta pergunta no SO para comparações extensivas do PostgreSQL com o MySQL, que dizem isso melhor do que eu.
• Ainda mais SO: Desvantagens do mysql versus outros bancos de dados

Usando RDBMSs em vez de outros tipos:

• Leia a idéia do "NoSQL" e outros tipos de banco de dados:
  • NoSQL: Se ao menos fosse assim tão fácil
  • (acima está linkado de) Quando usar o MongoDB ou outros sistemas de banco de dados orientados a documentos? ( mais )
  • /software/5354/are-nosql-databases-going-to-take-the-place-of-relational-databases-is-sql-going
  • Quando usar o CouchDB vs RDBMS
• Os RDBMS fazem uso pesado de indexação para desempenho. Em bancos de dados muito grandes, isso pode afetar negativamente o desempenho ou até reduzir o número ideal de linhas por DB / Shard, exigindo mais hardware
• Não é o ideal se você estiver armazenando uma quantidade enorme de dados, mas lendo com menos frequência
• Se você não possui muitos relacionamentos externos, os bancos de dados relacionais podem não ser ideais (armazenamento de documentos)

Tudo o que foi dito, o MySQL é um ótimo banco de dados, e eu não trabalhei em uma empresa nos últimos 8 anos que não o usou, em uma ampla variedade de aplicativos da web (como comércio eletrônico, sites / aplicativos) , empresa / B2B, jogos da Web). Para uma grande maioria dos casos de uso típicos de aplicativos da Web, é uma ótima opção.

O MySQL agora está sob o controle da Oracle - embora de código aberto eles ainda decidam a direção do projeto e o que entra.

Em termos de ser um banco de dados ruim, não, é apenas 'mais simples' do que alguns outros.

Se você está procurando pontos fracos, eu os apontarei para você, vamos usar o PostgreSQL, por exemplo.

1. O MySQL não possui tipos e matrizes de contêineres.
2. O MySQL não possui sequências verdadeiras (elas usam incremento automático) - as sequências do Postgres permitem que várias tabelas usem uma única sequência, para que você possa garantir cardinalidade em várias tabelas.
3. O Postgres é compatível com ACID, o MySQL é parcialmente compatível.
4. O Postgres implementa a variação de caracteres e o texto da mesma maneira (Toast Tables) - essa abordagem muitos argumentam que é melhor que o MySQL.
5. O Postgres possui apenas um back-end de armazenamento - isso significa que você garante os mesmos recursos em todos os lugares.
6. O Postgres permite funções do lado do servidor escritas em TCL, Python, R e Perl.
7. O Postgres tem um bom suporte para drivers assíncronos em Python - acho que é um pouco imprevisível com o MySQL

Historicamente, o suporte a transações era fraco, e as transações são importantes se você precisar manter um banco de dados consistente. Atualmente, o grande rap é que a Oracle é a dona.

Por um longo tempo, o MySQL foi mais um banco de dados "brinquedo". Ele não tratava de sub-seleções aninhadas, não suportava o particionamento de dados, não oferecia vários níveis de isolamento de transações, não suportava gatilhos ou procedimentos armazenados - muitas coisas. Muitas pessoas vindas do fundo do Oracle ou do SQL Server o demitiram.

Eu acho que a verdadeira razão pela qual você não vê muitas listas de deficiências do MySQL é que ele tem uma base de fãs bastante raivosa que exclui ou diminui o voto de qualquer menção pública a eles. Sei que, sempre que mencionei qualquer problema que tive, as respostas tendem a ser extremamente negativas.

O MySQL é compatível com ACID quando usado com o mecanismo de armazenamento InnoDB - não há razão para fazê-lo. O MySQL é compatível com ACID (a partir das versões 5.5, o InnoDB é o mecanismo de armazenamento padrão).

O MySQL recebe muita má imprensa porque é frequentemente usado (ou até o advento do NoSQL) como o RDBMS de escolha por pessoas que mal precisavam de um banco de dados (e talvez tivessem habilidades limitadas em RDBMS) e, portanto, o usavam de maneira desajeitada maneira.

Eu usei muito o MySQL e, desde que o 5.x apareceu, há muito pouco a reclamar sobre isso nos 95% das instalações que têm requisitos intermediários.

Corrupção de dados: http://planet.mysql.com/entry/?id=16232

É de 2008. Vamos torcer para que as coisas mudem nesse meio tempo.