Newsgroup: it.comp.os.dibattiti
Titolo: Re: [OT] Perche' usare MySQL e' sbagliato...

 windows ha una storia di schermate blu, mysql no.
MySQL ha di peggio. Si parla di corruzione dei dati: questo è qualcosa
che *non* deve succedere sotto nessuna ipotesi meno catastrofica di un
serio fallimento hardware, una guerra termonucleare fuori porta o
qualcosa del genere.
Poi a me Windows interessa poco: non lo uso e non lo voglio usare.
Invece la diffusione di MySQL (specie in mano a persone che non ne
conoscono i problemi) è qualcosa di discretamente pericoloso.
-- 
-riko

Enrico Franchi wrote:
hai fatto un mischiotto, hai messo roba vecchia 3.2 con roba nuova 5.1 in un
unico calderone.
hai messo in mezzo memcached che non c'entra nulla.
mi spieghi quando scade la sessione memcache dove vanno a finire i dati?
grazie
-- 
·

 questo che dovevo cercare (se puoi darmi una mano per cortesia) 
e perchè devi cercare "enrico franchi" per trovare dati riguardo alla
corruzione di dati di MySQL?
-- 
-riko

 hai messo in mezzo memcached che non c'entra nulla.
Non c'entra nulla? Credi che riuscirebbero a tenere in piedi Facebook
senza memcached? Mi spieghi come pretendi di andare a misurare le
performance del sistema quando hai in mezzo una cosa *esterna* (e in un
certo senso indipendente) al sistema?
-- 
-riko

 certo senso indipendente) al sistema?
ahah, e quindi  basta mettere tanti postgresql/mssql/oracle/firebird e sei
apposto. lasciamo perdere, veramente. non hai portato un'argomentazione che
sia una.
-- 
·

 fisso sulla drop database perchè gestiva la distruzione in modo casuale?
Posto che non capisco cosa c'entri un discorso su MySQL con icod
(caasomai era piu` corretto it.comp.software.database), vogliamo parlare
del fatto che la seguente query e` ritenuta valida?
SELECT order.custid, 
customer.name
, MAX(payments)
  FROM order,customer
  WHERE order.custid = customer.custid
  GROUP BY order.custid;
Enrico
P.S. no, non e` un bug e non e` presa da un sito qualsiasi, ma proviene
direttamente dalla documentazione di MySQL:
http://dev.mysql.com/doc/refman/5.1/en/group-by-hidden-fields.html

 apposto
E` questo il problema del fanatismo per un prodotto applicato ai
RDBMS. Si pensa che un db sia la panacea per tutti i mali.
Bene, ripetiamo tutti insieme: ogni RDBMS ha un suo contesto di
riferimento. Nello specifico, i db citati (sia nel topic, sia nel quote)
sono ottimi in molti contesti e pessimi in altri (e.g. e` impensabile
utilizzare Oracle in contesti in cui bisogna limitare le risorse,
contesti che vengono coperti in maniera eccelsa da Firebird). In tutto
questo pero` ci sono due costanti: la prima e` che MySQL ha presentato
(e presenta) dei seri problemi *oggettivi* di stabilita` e di
compatibilita`. La seconda, e` che tutti i RDBMS citati nel quote
sostituiscono egregiamente MySQL in qualsiasi compito si pensi di
utilizzarlo[1]
Enrico
[1] ok, non e` vero, Firebird riesce a servire meno query rispetto a
MySQL, ma in compenso e` molto piu` stabile, sia nel senso della
sicurezza dei dati, sia nel senso del rapporto numero di client/dati
serviti

 certo senso indipendente) al sistema?
Postgre non ha bisogno di cose esterne tipo memcached?
Ti ricordo che Postgre ha bisogno di cose esterne per fare la REPLICAZIONE
asincrona, eh... (cosa abbastanza fondamentale per scalare orizzontalmente
in un ambiente web)
-- 
Vide

 in un ambiente web)
In compenso non bisogna farsi a mano l'integrita' referenziale e non
bisogna tremare per la corruzione dei dati.
Ora bisogna inquadrare se la tua difesa per partito preso si riconduce
ad una stanca GPL vs. BSD (che nel caso c'entra come i cavoli a merenda,
visto che MySQL e' uno dei progetti piu' lontani dallo spirito open che
mi viene in mente) oppure al fatto che usi MySQL e lo devi difendere.
Ribadisco, MySQL cade sui fondamentali. E' squalificato in partenza, non
ci sono cazzacci. Direi che il post di Widenius fa chiarezza sul livello
di ciarlataneria cui si e' arrivati.
Io tutt'ora non capisco queste cose 'pro-mysql' che devono
necessariamente ignorare piu' o meno tutti gli aspetti tecnici per non
finire sul ridicolo.
-- 
-riko

 finire sul ridicolo.
Spiegalo alle carrettate di siti web che utilizzi anche tu che girano su
MySQL, creati da tecnici che non sono degli idioti.
In ogni caso, come sempre faccio quando ci sono flame su Mysql, sono il primo
ad ammettere che abbia difetti, e alcuni abbastanza gravi. Il fatto è che
non sono i classici difetti che la gente ripete a pappagallo quando si
vuole sparare FUD su Mysql. Per esempio possiamo dire che il QA è troppo
scadente, facendo uscire versioni con regression o nuovi bug stupidi, cambi
di implementazioni radicali da una minor all'altra e altre cosette di
questo stile.
-- 
Vide

 questo stile.
Possiamo anche dire che millanta feature che sono praticamente in
prealpha, e qui non sono sicuro che sia il QA, ma il reparto
mareketing seduto sui ginocchioni degli sviluppatori. Possiamo anche
dire che, almeno a mio avviso, scala di merda quando le esigenze si
fanno importanti, MySQL replica ad esempio rasenta lo scandalo, non so
se ti è mai capitato che una replica in-memory andasse fuori sync.
Possiamo anche dire che gli manca un optimizer e non ha particolari
doti di introspezione, il che è particolarmente divertente quando hai
un collo di bottiglia e come strumento per debuggare hai le viscere
degli animali che ti sei procacciato (aka EXPLAIN).
Se si tratta di uno storage persistente di dati, i motivi per usare
MySQL sono infinitamente meno che soltanto qualche anno fa, perchè la
velocità raw della base di dati è stata tolta dall'architettura di
base (in quanto piuttosto ininfluente) e l'affidabilità del software è
ormai quasi l'unico metro.
  ngw

 questo stile.
Che e' poi il fondo dell'articolo. Ma accidenti, ti rendi conto che ce
ne e' abbastanza per mollare un prodotto? Stiamo parlando di un DBMS,
non di un editor di testi. 
Bisogna fidarsi per i propri dati. Bisogna che certi bachi non siano
nelle versioni stabili. Conta il numero di bachi *critici*, e'
preoccupante.
Poi voglio dire, di codice legacy di merda da mantenere e' pieno il
mondo. Ma si dice anche che e' una merda. Non capisco perche' non dirlo
chiaro e tondo, e magari consigliare il prodotto anche per nuovi
software che non hanno problemi di legacy. 
-- 
-riko

 MySQL, creati da tecnici che non sono degli idioti.
Noi lo usiamo e fa schifo. Abbiamo sempre problemi coi lock anche se
eliminando le foreign key (!!) ne abbiamo meno, su macchine di sviluppo
si e` corrotto un paio di volte, alcune query faccio prima a eseguirle
io a mano, le join sono implementate alla cazzo, e` il database piu`
stronzo che conosca perche` per essere veloce richiede agli sviluppatori
di tenere a mente 3000 dettagli e 200 trucchi. Il planner e`
stupidissimo e fa differenza tra una chiave primaria (d1, d2) e (d2, d1)
e si potrebbe andare avanti ancora, ad esempio tutte le subquery le
tratta come correlate anche quando non lo sono e questo significa che
non le esegue atomicamente e che quindi se uno ne ha bisogno non puo`
fare affidamento al risultato, le ALTER TABLE e compagnia non sono
utilizzabili in transazioni perche` stanno nella tabella dei metadati
che e` MyISAM, quindi se succede qualcosa mentre gira un'alter table che
dura mezz'ora ti fa bene se non hai corrotto tutto il database e se
c'era un'errore in una serie di ALTER TABLE resti fottuto con un db
inconsistente.
Lasciamo stare su, mysql e` un prodotto del cazzo, fosse per me
sarebbero in mezzo alla strada da un pezzo. Il mio CTO invece lo vuole
usare perche` lo usano gli altri e 'ha una community migliore' qualsiasi
cosa voglia dire, noi restiamo coi problemi che abbiamo sebbene in
questo momento passare a postgresql non sarebbe un problema.
-- 
Valentino Volonghi aka Dialtone
http://stacktrace.it
 -- Aperiodico di resistenza informatica
Blog: 
http://www.twisted.it/
Public Beta: 
http://www.adroll.com/