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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [email protected] http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it.
