Togliamo di mezzo MySQL?

[cdimauro]

• 

MOD
:text-welcomewave:
Si continua da qui': viewtopic.php?f=35&t=423&p=3105#p3105
/MOD

-AmigaCori-

PostgreSQL è molto usato da quelle persone che vogliono un "vero" DB e da quelle persone che vogliono essere indipendenti da una licenza virale come la GPL.

Sante parole!

MySQL ha sempre implementato un subset di SQL per motivi prestazionali, motivo per cui è scelto (stupidamente) da molti. Ora non sono aggiornato, ma ho sempre reputato una scelta stupida preferire MySQL perché più semplice e quindi più veloce. Quando non supportava subquery e stored procedure, per quanto veloce fosse la sua implementazione, su PostgreSQL potevi scrivere codice SQL che era oltre 100 volte più performante.

MySQL andava molto bene con MyISAM o con MemTable, ma non per consistenti carichi di lavoro in cui i dati DEVONO essere consistenti, caso questo piuttosto comune quando non hai a che fare col sitarello casereccio, insomma.

Quindi in scenari seri NON avendo a disposizione un engine ACID, erano uccelli per diabetici. E se volevi emulare parte delle caratteristiche dovevi impiegare pesantemente i client (magari scritti in PHP o Perl, giusto per aumentare l'inefficienza), facendo crollare le prestazioni (d'altra parte client e server dovevano comunicare continuando scambiandosi informazioni...).

Tant'è che usando engine ACID e con un certi carichi di lavoro non c'è proprio storia fra MySQL e altri engine seri (come quelli citati finora). Per non parlare della mancanza di stored procedure, trigger, view, e altre cosette carucce come i domain, ma potrei parlare anche dell'incredibile assenza delle user exception che tuttora ti fa sputare sangue se vuoi scrivere un SP o un trigger più avanzato. O della mancanza di un software di backup in tempo reale (ci sono soluzioni, ma a pagamento e MOLTO CARE, e solo per alcuni engine come InnoDB). O, peggio ancora, provate a cambiare lo schema di una tabella grassottella; chessò, aggiungere o rimuovere un campo, e vedrete che per portare a termine l'operazione può impiegare anche delle ore, mentre ovviamente quella tabella rimarrà LOCKATA PER TUTTO IL TEMPO!!! E se sei fortunatissimo magari nemmeno riesce a portare a termine l'operazione. :lol:

E lasciamo perdere i numerosi e grossolani bug che ci sono, poi...

(edit)
Oltre al fatto che succede spesso che il DB di MySQL subisca danni, credo per scelte architetturali sbagliate in passato. Nelle prime versioni MySQL storava su flatfile.
(/edit)

Perché, l'altra megastronzata non è l'aver usato il filesystem per memorizzare le tabelle? Così sui sistemi Unix-like, dove imperano quelle cacate di filesystem case sensitive, se non azzecchi il case preciso del nome di una tabella, ti dice che NON l'ha trovata, in barba allo standard SQL che prevede che tutti gli identificatori siano case insensitive, ed è così per tutto il resto per fortuna, ma ti ritrovi un sistema incoerente.

La cosa carina è che sui sistemi con filesystem case insensitive tutto è coerente, ma... forza a lowercase tutti i nomi delle tabelle quando le elenchi con SHOW TABLES, quando potrebbe benissimo visualizzarle col loro naturale case, visto che non possono succedere danni.

E così se lavori allo stesso progetto in locale su Windows e in produzione su Linux, e fai uso di un sistema come ORM et similia che fanno introspezione dei metadati per costruirsi le classi -> tabelle e lavorarci, o non ti funziona una mazza o sputi sangue per risolvere i problemi che artificiosamente crea quest'abominio di engine.

OK, la finisco qui perché ho già lo stomaco che mi si sta rivoltando a parlare di MySQL, e quindi la giornata è iniziata male. :angry-banghead:

[lucommodore]

• 

@cdimauro
Ecco adesso che ho letto il tuo post se vedo "un mysql" rabbrividisco e me la do a gambe terrorizzato.
E io convintone (convinto+giandone) che pensavo fosse un DB stravalido  :doh:

[cdimauro]

• 

Se lo conosci, lo eviti. Se lo conosci, non ti uccide...

EDIT: Qui trovate una presentazione con dei benchmark su Firebird (che anticipo ne esce vincitore), MySQL e PostgreSQL.

[cdimauro]

• 

Beh, quel test è stato fatto nel 2009 (tra l'altro su un'alpha di FB 2.5, il che è tutto dire), e all'epoca c'era solo la 8.4 di PostgreSQL.

P.S. Se non ricordo male MySQL è diventato "stabile" dalla 3.28, mentre PostgreSQL dalla 7. Ma non ci metto la mano sul fuoco, perché è passato troppo tempo da quando ho letto i rispettivi annunci della milestone.

[lucommodore]

• 

Te ne racconto una (o meglio, la prima) (...)

:shock:
Che disastro compare, immagino le bestemmie...
In effetti la mia (poca, breve e non certo specializzata) esperienza con mysql fu di piccoli sitarelli  ma non immaginavo assolutamente una robaccia del genere in applicazioni più importanti.
Beh ora in caso saprò regolarmi meglio all'eventuale bisogna.
Però a 'sto punto mi fa un po 'arrabbiare il fatto che difficilmente si trova qualcuno che descriva questi problemi sul mysql (ad es. quanto hai riportato da wikipedia sul paragone prosaico col postgreSQL), ne parlano tutti bene... Mi vien da pensare che rispetto a quello di quanti ci giochichiano con i DB, il numero dei professionisti sia veramente veramente esiguo :doh:

[ncc-1700]

• 

Premesso che sono d'accordo al 100% con quanto espresso nel thread, vorrei solo ricordare che MySQL (che nasce dalle ceneri di mSQL) NON è mai stato progettato per gestire grande mole di dati o per gareggiare con Oracle o Infromix, ma per essere il più veloce e maneggevole possibile. Il suo punto di forza doveva essere rispondere velocemente a semplici query. Il suo scopo era permettere con poco investimento di essere usato come base dati di siti internet, quindi di gestire non dati esagerati e complessi e di rispondere alle query nel minor tempo possibile. Difatti non ha mai avuto se non negli ultimi tempi, stored procedure, macro replicazione et similia. Poi hanno voluto (visto l'iniziale successo) trasformarlo in un database di razza superiore, lanciandolo così verso il ridicolo. Perdonatemi, ma chiunque pensasse di migrare database Oracle su MySQL NON è un database administrator....... sono cose che vanno gestite con attenzione ed un buon Capacity Manager sotto mano. Conosco ancora CED che hanno, come se non erro diceva dsar , macchine come DEC, Alpha, arcaici HP o AIX, solo perchè la migrazione a sistemi più moderni non è ancora stata validata....... progetti di migrazione ad applicativi Siebel, PeopleSoft etc in sviluppo da anni ma senza arrivare ad un punto di concrete prestazioni; figuriamoci progetti di migrazione a MySQL. Certo qualche cosa ho visto, ma la mole dei dati e la loro criticità non era certo elevata e la migrazione comunque non è stata facilissima...

My 2cent's
ncc-1700

[cdimauro]

• 

D'accordissimo. Tra l'altro della storia di MySQL e di PostgreSQL se n'è parlato proprio in un articolo di AD di qualche giorno fa: http://www.appuntidigitali.it/16037/la- ... en-source/

I precedenti articoli sull'argomento hanno parlato di DB2, Oracle, Sybase, MSSQL.

[cdimauro]

• 

Subscribed!

[ncc-1700]

• 

Ovviamente non tutto è da buttare, specialmente se si usa una visione aperta e libera come quella attuata da Giuseppe Maxia su Linux&C. N72 a partire da pagina 18, dove ne fa un ritratto abbastanza vincente, anche se secondo me troppo ottimistico e positivo.

Ciao,
ncc-1700

[cdimauro]

• 

Non so se è una fortuna (e a questo punto, viste le conclusioni, penso proprio di sì), ma non l'ho mai letto.