Le insidie ​​dell'utilizzo di MySQL come scelta del database? [chiuso]

Ho letto online in più occasioni che MySQL è un cattivo database. I luoghi che ho letto includono alcuni thread su Reddit, ma non sembrano mai approfondire il motivo per cui è un prodotto scadente.

C'è qualche verità in questa affermazione? Non l'ho mai usato oltre uno scenario CRUD molto semplice, e quello era per un progetto universitario durante il mio secondo anno.

Quali insidie, se presenti , ci sono quando si sceglie MySQL come database?

Esistono due diversi tipi di insidie, quelli dell'utilizzo di MySQL come tipo di RDBMS e quelli dell'utilizzo di un RDBMS invece di altri tipi di database.

Utilizzando MySQL invece di RDBMS alternativi:

• Vedi questa tabella di confronto di Wikipedia per vari confronti di MySQL con altri RDBMS.
• Probabilmente preferirai Microsoft SQL Server se stai creando un'applicazione web ASP.NET, poiché il sistema è progettato per funzionare bene insieme, credo sia per gli sviluppatori che per i responsabili IT
• Potresti preferire Oracle se hai bisogno di una configurazione DB più avanzata che coinvolga il clustering (Oracle RAC) o procedure DB avanzate. Non che MySQL non supporti molte delle funzionalità, ma da quello che ho visto, è molto più probabile trovare un DBA esperto che conosca queste cose per Oracle rispetto a MySQL.
• Vedi questa domanda su SO per ampi confronti di PostgreSQL con MySQL che lo dicono meglio di me.
• Ancora più SO: svantaggi di mysql rispetto ad altri database

Utilizzo di RDBMS invece di altri tipi:

• Leggi l'idea di "NoSQL" e altri tipi di DB:
  • NoSQL: se solo fosse così facile
  • (sopra è collegato da) Quando utilizzare MongoDB o altri sistemi di database orientati ai documenti? ( altro )
  • /software/5354/are-nosql-databases-going-to-take-the-place-of-relational-databases-is-sql-going
  • Quando utilizzare CouchDB vs RDBMS
• Gli RDBMS fanno un uso pesante dell'indicizzazione per le prestazioni. Su database molto grandi, ciò può influire negativamente sulle prestazioni o addirittura ridurre il numero ottimale di righe per DB / Shard che richiedono più hardware
• Non è l'ideale se si memorizza una grande quantità di dati ma si legge meno frequentemente
• Se non si hanno molte relazioni estere, i database relazionali potrebbero non essere l'ideale (archiviazione dei documenti)

Detto questo, MySQL è un ottimo database e non ho lavorato in un'azienda negli ultimi 8 anni che non lo ha utilizzato, in una vasta gamma di applicazioni Web (come e-commerce, siti Web / app , impresa / B2B, giochi web). Per la maggior parte dei casi d'uso tipici delle applicazioni Web, è un'ottima scelta.

MySQL è ora sotto il controllo di Oracle, anche se open source decidono ancora la direzione del progetto e cosa entra.

In termini di database errato, no, è solo "più semplice" di altri.

Se stai cercando punti deboli, te li segnalerò per te, prendiamo PostgreSQL per esempio.

1. MySQL manca di tipi e array di contenitori.
2. MySQL non ha sequenze reali (usano l'auto-increment) - Le sequenze Postgres consentono a più tabelle di utilizzare una singola sequenza in modo da poter garantire la cardinalità su più tabelle.
3. Postgres è conforme ACID, MySQL è parzialmente conforme.
4. Postgres implementa la variazione dei caratteri e il testo allo stesso modo (Tabelle Toast) - questo approccio che molti sostengono sia migliore di MySQL.
5. Postgres ha un solo back-end di archiviazione: ciò significa che avrai le stesse funzionalità ovunque.
6. Postgres consente funzioni lato server scritte in TCL, Python, R e Perl.
7. Postgres ha un buon supporto per i driver asincroni in Python - Penso che sia un po 'sbagliato con MySQL

Storicamente, il supporto delle transazioni era debole e le transazioni sono importanti se è necessario mantenere un database coerente. Al giorno d'oggi, il grande rap è che Oracle lo possiede.

Per molto tempo MySQL è stato più un database "giocattolo". Non gestiva le sotto-selezioni nidificate, non supportava il partizionamento dei dati, non offriva più livelli di isolamento delle transazioni, non supportava trigger o procedure memorizzate - molte cose. Molte persone provenienti da background Oracle o SQL Server lo hanno respinto.

Penso che il vero motivo per cui non vedi molti elenchi delle carenze di MySQL sia che ha una base di fan piuttosto rabbiosa che cancella o declassa qualsiasi menzione pubblica di essi. So che ogni volta che ho menzionato i problemi che ho avuto con esso, le risposte tendono ad essere estremamente negative.

MySQL è compatibile con ACID se utilizzato con il motore di archiviazione InnoDB - nessun motivo per non farlo così MySQL è compatibile con ACID (a partire dalla versione 5.5 InnoDB è il motore di archiviazione predefinito).

MySQL riceve molta cattiva stampa perché viene spesso utilizzato (o lo era fino all'avvento di NoSQL) come RDBMS di scelta da persone che avevano a malapena bisogno di un database (e forse avevano competenze RDBMS limitate) e quindi lo usavano in modo piuttosto goffo maniera.

Ho usato MySQL molto e da quando è arrivato 5.x c'è ben poco di cui lamentarsi per il 95% delle installazioni che hanno requisiti intermedi.

Corruzione dei dati: http://planet.mysql.com/entry/?id=16232

È del 2008. Speriamo che le cose siano cambiate nel frattempo.