[Gfoss] Sun compra MySQL

[a.furieri a lqt.it]

On Fri, 18 Jan 2008 13:10:43 +0100, Andrea Peri wrote

> Approfitto di questo interscambio per porti una domanda.
> Mi risultava che MySQL presentasse qualche problema spinoso quando si
> effettua il porting dei dati da un MySQL su Linux e un MySQL su
> Windows (o viceversa non ricordo bene).
> 
> E' ancora cosi', o la situazione e' cambiata con la 6 ?.
> 
> Andrea.
> 

Boh ... a me non risulta proprio, anzi ...
Il problema di MySQL e' che supporta un sacco di
data engines totalmente differenti, quindi quando
senti dire "MySql fa questo e quello" spesso siamo 
allo sciocchezzaio puro e semplice; una enunciazione
corretta dovrebbe sempre indicare di quale engine
stiamo parlando.
Ad ogni buon conto, la versione stabile corrente
e' la 5.0; la 5.1 e' ancora in pre-produzione, 
e la 6.0 inizia ora a muovere i primi passi in alpha.

engine MyISAM
-------------
Probilmente e' quello usato piu' diffusamente,
perche' e' il piu' veloce ed il piu' semplice
da gestire.
Un database/schema e' semplicemente una directory; 
ciascuna tavola risiede in una tripletta di files
.MYD .MYI .FRM [dati, indici, formato].
Non e' per nulla ACID, non supporta le transazioni,
non implementa i constraints primary/foreign key,
pero' supporta gli R-trees per gli spatial index.
Se usi questo engine, basta semplicemente copiare 
la directory ed i files che contiene per spostare
fisicamente il DB da una piattaforma ad un'altra.
Molto tempo fa c'e' stata una modifica nei formati
dati, per cui occorreva usare un qualche tool di 
conversione per riutilizzare i vecchi dati sulle
nuove versioni, ma stiamo parlando del paleolitico ..

engine InnoDB
-------------
A me personalmente piace molto; e' full-acid,
supporta le transazioni, i constraints relazionali
etc; richiede una sapiente ottimizzazione [ed una
barca di ram] per girare realmente veloce. 
Insomma, diciamo che non e' alla portata "di dilettante";
se lo vuoi spremere fino in fondo occorre un classico 
approccio "da sistemista".
Peccato che supporta gli Spatial data, ma non implementa
gli Spatial Index, quindi nel GIS serve praticamente
a nulla.
Questo engine usa un unico file [oppure una catena
di segmenti, sia con allocazione fissa che dinamica]
per memorizzare tutto [dati, indici, definizioni, etc] +
un secondo file per memorizzare le transazioni.
Personalmente a me è successo di dovere spostare un
DB InnoDB da 40GB da un disco ad un altro, e mi e'
ripartito senza alcun problema.
[ovviamente questo genere di operazioni vanno fatte col 
DB disattivato, altrimenti se hai accessi in corso il 
disastro e' garantito]  

engines MaxDB, MEMORY, BDB, etc
-------------------------------
Non so dirti nulla. Mai usati.

engine FALCON
-------------
Ancora e' molto molto acerbo. Dovrebbe diventare
lo standard a partire dalla 6.0, ma ancora manca
almeno un anno prima di potere mettere le mani
su qualcosa di ragionevolmente stabile.
E' full-acid, dovrebbe essere molto veloce e
soprattutto dovrebbe essere "intelligentemente
autoconfigurante", quindi non dovrebbe richiedere
nessuna attività amministrativa. 
Se e quando sara' disponibile mandera' in pensione 
sia MyISAM che InnoDB ... aspettiamo che arrivi ...

ciao Sandro