MySQL dalle origini ad oggi
Il progenitore di MySQL è mSQL (miniSQL), sviluppato da Hughes Tecnology (australiana).
Nei primi anni '90 Michael "Monty" Widenius, uno sviluppatore svedese della società TcX utilizza la versione 1.x di mSQL
che però non supportava gli indici, decide quindi di aggiungere delle funzionalità ralizzando nel 1995 MySQL 1.0
(my deriva dal fatto che la moglie si chiamava My e che le tabelle utilizzavano my come suffisso).
MySQL AB è una società virtuale (decine di paesi comunicazioni via internet) svedese con David Axmark e Allan Larsson.
Vogliono promuovere la filosofia Open Source e nel 2000 utilizzano la GPL (Gnu Public License) per MySQL
MySQL è classificabile come un "database relazionale" permettendo la conservazione dei dati in tabelle separate piuttosto che in una unica grande entità. Questo, oltre ad aggiungere flessibilità e velocità nell'accesso ai dati, permette una più efficace modellazione delle basi di dati.
Il sistema si presenta con una struttura client/server, dove il server SQL, scritto in C e C++, utilizza una architettura multithread e offre una completa raccolta di API (Application Programming Interfaces) utilizzabili sia tramite i client forniti nella distribuzione sia da applicazioni scritte in una notevole varietà di linguaggi: C, C++, Eiffel, Java, Perl, PHP, Python, Ruby e TCL.
Il fatto di essere Open Source ha inoltre favorito lo sviluppo di interfacce, rilasciate ovviamente sotto GPL, in pressoché tutti i linguaggi maggiormente utilizzati, soprattutto nello sviluppo di applicazioni web ma non solo: in PHP ad esempio viene fornita in modo nativo al linguaggio la connettività al database server, in Perl la connessione è possibile grazie ai moduli DBI e DBD::MySql, utilizzando MySQL Connector/ODBC (MyODBC) è possibile connettersi al database utilizzando applicazioni come ad esempio Microsoft Access, Microsoft Excel o linguaggi di programmazione come Delphi Borland o ASP e Visual Basic, viene inoltre fornito supporto ai client Java, sia in ambiente Windows che Unix, tramite l'interfaccia Connector/JDBC.
L'accesso ai dati è reso possibile dall'utilizzo di SQL (Structured Query Language), in particolare viene garantito il supporto alla versione corrente dello standard definito nel ANSI/ISO SQL Standard.
Opensource e gratuito:
Il database server mySQL è rilasciato dalla società che lo sviluppa, la mySQL AB, prima di tutto secondo la filosofia dell'Opensource, in secondo luogo in forma gratuita (Supporto tecnico a parte).
I vantaggi di avvalersi di prodotti Opensource sono molteplici, di seguito ne elencherò alcuni:
- Rilascio del codice sorgente:
- In questo modo si ha la garanzia che il software sia controllato e testato dall'intera
comunità Opensource e non solo dagli sviluppatori e debugger.
Un altro aspetto positivo è che se un giorno la mySQL AB fallisse o semplicemente
interrompesse lo sviluppo del prodotto questo molto probabilmente sarebbe
sviluppato direttamente dalla comunità Opensource.
- Gratis:
- Un'altro enorme vantaggio è il rilascio di mySQL a costo 0$
- Continui miglioramenti e features:
- Grazie al supporto della comunità la società che mantiene lo sviluppo di mySQL è
in grado di rilasciare nuove versioni con una velocità davvero impressionante,
queste nuove versioni solitamente contengono bug fix, nuove features, migliorie
ecc...
Dopo aver affrontato gli aspetti favoreli di mySQL è giusto parlare anche dei limiti che mySQL ha in questo momento, parlo di “questo” momento perchè nei piani di sviluppo della mySQL AB è in previsione l'uscita delle versioni 4.1.x e 5.0.x che copriranno completamente o almeno in grande quantità il gap di features che attualmente ha mySQL nei confronti dei database server considerati di livello Enterprise (Es. Oracle, Informix ecc...).
Alcune delle limitazioni principali sono elencate di seguito:
Integrità referenziale:
Questa era senza dubbio la mancanza principale di mySQL rispetto ad altri database (tra cui anche Access) che però è stata sopperita mediante l'implementazione delle tabelle INNODB (seguiranno approfondimenti) che supportano le chiavi esterne.
Ve ne parlo perchè ritengo personalmente che il supporto ad INNODB (tipo di tabella che studieremo tra poco) sia ancora abbastanza instabile sia dal punto di vista delle performance che si ottengono utilizzando questi tipi di tabelle, sia per l'impossibilità ad utilizzare gli indici FULLTEXT (tipo di indice, seguiranno approfondimenti).
In sostanza prima dell'introduzione di questi tipi di tabelle l'utilizzo e il mantenimento delle chiavi esterne era affidato esclusivamente allo sviluppatore e di conseguenza il relazionamento tra le tabelle era garantito a livello logico e di implementazione dell'applicazione.
ESEMPIO PRATICO:
TABELLA PERSONA
IDpersona Nome Cognome
1 Massimo Caselli
2 Paolo Pippo
TABELLA TELEFONO
IDtelefono IDpersona Telefono
1 1 039/393030
2 2 039/393930
Supponiamo di eliminare il record numero 1 della tabella PERSONA, con mySQL senza utilizzo di INNODB bisogna provvedere, lato applicazione,ad eliminare dalla tabella TELEFONO anche il record in cui Idpersona vale 1.
In caso contrario si avrebbe nella tabella TELEFONO un record “orfano” della propria relazione con la tabella PERSONA.
Transazioni:
Quando si lavora con i database relazionali ci si trova in alcune situazioni a dover eseguire una serie di query di inserimento su diverse tabelle del database server, prendiamo come esempio l'aggiunta di una persona e di un numero di telefono alla nostra semplice rubrica dei contatti.
In questo caso dovremo eseguire queste operazioni:
- Inserimento nella tabella PERSONA
- Recupero dell'ID del nuovo record inserito in PERSONA
- Inserimento del numero di telefono precedentemente immesso da applicazione, con relativa associazione all'ID della persona appena aggiunta
Se durante uno di questi passaggi il DB andasse in crash, rischieremmo di avere nel database una nuova persona senza un numero di telefono associato.
Per ovviare a queste problematiche alcuni DB server gestiscono i gruppi di comandi SQL tramite transazioni, in sostanza l'inserimento reale dei dati avviene SOLO se tutte le istruzioni sono state eseguite correttamente.
In realtà anche questa problematica è stata risolta da mySQL con l'introduzione delle tabelle di tipo INNODB.
Stored procedures:
I server considerati di livello enterprise consentono di inserire all'interno del database stesso del codice procedurale.
Il che consente prima di tutto di semplificare il codice a livello applicativo ed in seconda battuta di migliorare le performance in quanto il DB server gestisce al meglio il codice da eseguire.
Box descrizione MySQL 5 Beta
da scrivere
Ciao a tutti,
affrontiamo di seguito un confronto tra le tabelle MyISAM (le classiche di MySQL) e le innovative INNODB (relativamente).
Cerchiamo innanzitutto di schematizzarne le differenze:
MyISAM (Default engine di MySQL)
Sono le tabelle storiche di MySQL, derivanti direttamente dalle vecchie ISAM che sono dismesse ormai da anni.
Garantiscono indubbiamente un’ottima affidabilità e velocità. Su versione di MySQL più vecchie della 4.1 sono sicuramente da preferirsi alle INNODB.
Forniscono un vantaggio notevole che è dato dalla possibilità di poter utilizzare indici FULLTEXT per ricerche con ranking stile Google.
Il metodo di salvataggio dei dati è basato sulla costruzione e lavorazione di 3 file binari:
* frm
Struttura della tabella
* MYD
File contenente tutti i dati della tabella
* MYI
File contenente i dati relativi agli indici del database
Inutile sostituirsi ai manuali… :-D
Per maggiori informazioni: http://dev.mysql.com/doc/refman/5.0/en/myisam-storage-engine.html
INNODB
Sempre più spesso capita di trovare database server le cui tabelle di default utilizzano l’engine INNODB.
Tale scelta è dettata dalla sempre più importanza anche per progetti web di funzionalità che normalmente MySQL con le semplici tabelle MyISAM non fornisce.
Vediamo quindi una serie di funzionalità avanzate garantite dalle tabelle INNODB:
* Foreign Key
Le tabelle INNODB sono in grado di gestire l’integrità referenziale tra le chiave esterne del database, in sostanza tale integrità è sempre stata delegata all’abilità dello sviluppatore, ora con il motore INNODB è possibile delegare questa annosa attività a MySQL stesso, potendo quindi specificare vari comportamenti a seconda della chiave esterna utilizzata.
* Transazioni
Le transazioni sono fondamentali in situazioni tipiche da shop online dove sino a che non arriva conferma da parte della banca o di chi valida la carta di credito, le query non devono essere “eseguite realmente”.
Fondamentalmente si tratta di eseguire una serie di query che verranno validate o annullate mediante chiamate COMMIT o ROLLBACK.
* Mancanza - FULLTEXT
Cito ora una mancanza grave nelle tabelle INNODB, l’assenza di poter (almeno per ora) dichiarare un campo come indice fulltext per poter eseguire ricerche con score alla Google.
Queste sono le principali funzionalità aggiuntive di INNODB rispetto a MyISAM, come sempre per maggiori informazioni vi rimando al manuale ufficiale di MySQL: http://dev.mysql.com/doc/refman/5.0/en/innodb-overview.html
COME SCEGLIERE LE TABELLE????
Cercherò ora di dettare due linee guide per stabilire se conviene realizzare tabelle MYISAM o INNODB.
Innanzitutto come sempre dipende dal contesto di applicazione.
Una breve premessa sulle performance… a mio parere la velocità dei due motori è pressochè la stessa.
Se necessitiamo di transazioni, supporto all’integrità referenziale perchè dobbiamo realizzare un’applicazione con shop online o un magazzino con carico/scarico (N.D.R. si può fare tutto ciò anche con MyISAM) utilizzerei le tabelle di tipo INNODB, altrimenti utilizzerei le MyISAM in quanto hanno due vantaggi grandissimi, supporto FULLTEXT e soprattutto è possibile fare un backup diretto dei file binari per l’importazione/esportazione della base dati.
Con le tabelle INNODB è invece molto complesso in quanto i dati di TUTTI i database presenti sul server e che utilizzano tabelle INNODB vengono normalmente salvati nel file ibdata1.
Anche volendo salvare i file dei dati ognuno per tabella le transazioni e gli indici vengono comunque salvati nel TABLESPACE e quindi il recovery mediante import di tutti i file presente per esempio sotto: /var/lib/mysql/miodb/ NON FUNZIONA!
Sperando di essere stato il più chiaro possibile vi saluto.
Ciao. Max
info[AT]massimo-caselli[DOT]com