Nuova versione per SQlite 3.6.17, server leggero e flessibile perfettamente aderente agli standard SQL
SQLite è una libreria software scritta in linguaggio C che implementa un DBMS SQL incorporabile all'interno di applicazioni. Il suo creatore è D. Richard Hipp, che lo ha rilasciato come software Open Source di pubblico dominio, privo di qualsiasi licenza. Permette di ottenere una base di dati (comprese tabelle, query, form, report) incorporate in un unico file, come il modulo Access di Microsoft Office o il modulo Base di OpenOffice.org, o prodotti specifici come Paradox o FileMaker Pro.
SQLite è un database server leggero e flessibile perfettamente aderente agli standard SQL. Non è potente come MySQL o PostgreSQL, ma rappresenta la soluzione ideale per applicazioni embedded o comunque di dimensioni ridotte che fanno della leggerezza e della velocità di esecuzione i loro punti di forza.
Essendo una libreria, non è un processo standalone utilizzabile di per sé, ma può essere linkato all'interno di un altro programma. È utilizzabile con linguaggio C/C++ ed esistono binding anche per altri linguaggi, in particolare Tcl. È integrato nella versione 5 di PHP, consentendogli di non aver più bisogno di appoggiarsi ad un RDBMS esterno come MySQL e divenendo più concorrenziale rispetto alla piattaforma web ASP.NET di Microsoft. A sua volta MySQL è stato costretto a sviluppare la versione 5 con la gestione delle nuove tabelle InnoDB per diventare più simile/più concorrenziale ad altri importanti database "open" come PosgreSQL e Firebird.
Il pacchetto ha molte interessanti caratteristiche:
- È molto piccolo (meno di 500KB per l'intera libreria alla versione 3.6.14).
- È molto veloce; in molti casi più di MySQL e PostgreSQL.
- Il codice sorgente è liberamente disponibile, chiaro e ben commentato
- È in grado di interpretare stringhe SQL, a differenza di altre librerie simili; supporta buona parte dello standard SQL92.
- L'API è semplice da utilizzare
- Ha transazioni atomiche, consistenti, isolate e durabili (ACID), anche in caso di crash di sistema o blackout.
- È multipiattaforma.
- Contiene un programma di utilità che permette l'accesso al database anche manualmente (come su MySQL, Postgresql e tanti altri DB) o tramite scripting.
- Supporta database che possono essere anche molto grandi; attualmente il limite è 2TB (241 byte).
- Il database consiste di un unico file il cui formato interno è indipendente dalla piattaforma e dal relativo Ordine dei byte.
- Non ha dipendenze esterne.
- Normalmente non richiede alcun lavoro di amministrazione, ma supporta il comando SQL VACUUM nel caso si renda necessario comprimere il database.
SQLite presenta dei limiti legati in parte alla finalità di semplice database da incorporare in altre applicazioni:
- Non possiede le stored procedure.
- Non prevede la gestione dei permessi (demandata al software con cui si interagisce con il database o al File System.
- Non ha una vera gestione della concorrenza: le applicazioni che lo utilizzano, se necessario, devono implementarla.
- Per garantire la coerenza del file del database si appoggia al lock del File System e quindi può dare problemi qualora quest'ultimo non lo implementi correttamente ad esempio per risorse in rete (come NFS).
- Non offre alcuna cache per le query (e non ne ha la possibilità, non esistendo un processo server centrale).
- Non ha protocolli di rete, non essendo utilizzabile come programma standalone; è possibile utilizzare un database in remoto, ma solo servendosi del File system del sistema operativo, con prestazioni difficilmente accettabili.
- Non è in grado di gestire dati binari in modo sicuro.
- Non supporta alcuni importanti comandi SQL quali RIGHT e FULL OUTER JOIN.
- Non supporta le sottoquery variabili.
- Non supporta la scrittura nelle viste
- Il comando ALTER TABLE è limitato alla modifica del nome della tabella e all'aggiunta di colonne alla fine.
- Non supporta vincoli sulle chiavi esterne comunque simulabili tramite TRIGGER
Una peculiarità di SQLite è la gestione flessibile dei tipi di dati: ogni campo può contenere qualsiasi tipo di dato (o quasi; gestito differentemente nella versione 2 e 3).
SQLite presenta dei limiti legati in parte alla finalità di semplice database da incorporare in altre applicazioni:
- Non possiede le stored procedure.
- Non prevede la gestione dei permessi (demandata al software con cui si interagisce con il database o al File System.
- Non ha una vera gestione della concorrenza: le applicazioni che lo utilizzano, se necessario, devono implementarla.
- Per garantire la coerenza del file del database si appoggia al lock del File System e quindi può dare problemi qualora quest'ultimo non lo implementi correttamente ad esempio per risorse in rete (come NFS).
- Non offre alcuna cache per le query (e non ne ha la possibilità, non esistendo un processo server centrale).
- Non ha protocolli di rete, non essendo utilizzabile come programma standalone; è possibile utilizzare un database in remoto, ma solo servendosi del File system del sistema operativo, con prestazioni difficilmente accettabili.
- Non è in grado di gestire dati binari in modo sicuro.
- Non supporta alcuni importanti comandi SQL quali RIGHT e FULL OUTER JOIN.
- Non supporta le sottoquery variabili.
- Non supporta la scrittura nelle viste
- Il comando ALTER TABLE è limitato alla modifica del nome della tabella e all'aggiunta di colonne alla fine.
- Non supporta vincoli sulle chiavi esterne comunque simulabili tramite TRIGGER
Una peculiarità di SQLite è la gestione flessibile dei tipi di dati: ogni campo può contenere qualsiasi tipo di dato (o quasi; gestito differentemente nella versione 2 e 3).
Ci sono, naturalmente, anche degli svantaggi:
* non possiede stored procedure, gestione dei permessi e molte altre funzionalità tipiche dei "colossi"
* non ha una vera gestione della concorrenza (le applicazioni che lo utilizzano, se necessario, devono implementarla)
* non offre alcuna cache per le query (e non ne ha la possibilità, non esistendo un processo server centrale)
* non ha protocolli di rete, non essendo utilizzabile come programma standalone; è possibile utilizzare un database in remoto, ma solo servendosi del filesystem del sistema operativo, con prestazioni difficilmente accettabili
* non è in grado di gestire dati binari in modo sicuro
* non supporta alcuni importanti comandi SQL:
o RIGHT e FULL OUTER JOIN
o sottoquery variabili
o transazioni annidate
o ALTER TABLE offre pochissime possibilità
Una sua peculiarità è il gestire i "tipi" in modo molto flessibile: ogni campo può contenere qualsiasi tipo di dato (o quasi; gestito differentemente nella versione 2 e 3).
Ricordiamo che SQLite non è un server e che un database SQLite è costituito da un file binario accessibile direttamente, quindi risulta influenzato dalle restrizioni imposte dai Chmod con Php e da configurazioni legate a Php come il Safe Mode e configurazioni sicure.
L'accesso diretto ad un database SQLite non richiede username e password, mentre l'accesso remoto (http:// o ftp://), a differenza di quanto avviene nel caso dei file DBM, non è supportato dall'API Php: in entrambi i casi non si tratta di vere e proprie limitazioni, infatti stiamo parlando di un database engine pensato per essere utilizzato sulla stessa macchina in cui opera Php.
sqlite_open() consente di creare un database o di aprirlo se già esiste,
resource sqlite_open ( string filename [, int mode [, string &error_message]])
Il primo argomento, il file, è l'unico obbligatorio: per evitare effetti imprevedibili è preferibile utilizzare un percorso fisico assoluto (facilmente ricostruibile con funzioni come getcwd() e realpath()).
Al posto di un file presente sull'hard disk possiamo anche utilizzare ":memory:" per creare un database temporaneo (con vita pari alla durata dello script) residente soltanto memoria, una caratteristica che può tornare utile per caricare/scaricare provvisoriamente dati durante alcune operazioni di manipolazione.
"mode" per ora non ha nessun ruolo se non quello di segnaposto, ma in futuro avrà il compito di definire la modalità di accesso al file.
Il terzo argomento rappresenta un contenitore per gli errori in caso di fallimento al momento dell'apertura, tuttavia non sembra funzionare come dovrebbe (specialmente in Windows), quindi al momento è consigliabile utilizzare sqlite_open() come segue.
<?php
/* [LISTATO 1]
Attiviamo il tracking degli errori:
In caso di errore soppresso con "@" troveremo il messaggio
nella variabile PHP predefinita "$php_errormsg".
Si tratta di un modo per sopperire al non funzionamento del terzo argomento di sqlite_open
*/
ini_set('track_errors', '1') ;
/*
Percorso assoluto del database
*/
$dbFile = realpath('./').'/testDB1' ;
$dbLink=@sqlite_open($dbFile) ;
/*
Se qualcosa è andato storto gestiamo l'errore e stampiamo un avviso
*/
if(!is_resource($dbLink)){
$sqliteError= "Si è verificato un errore al momento dell'apertura/creazione del database <br>\n";
$sqliteError.= '<strong>'.$php_errormsg.'</strong>' ;
$php_errormsg='' ;
die($sqliteError) ;
}
//altre operazioni
/*
Chiude il database
*/
sqlite_close($dbLink) ;
?>
Se ti è piaciuto l'articolo , iscriviti al feed cliccando sull'immagine sottostante per tenerti sempre aggiornato sui nuovi contenuti del blog:
Nessun commento:
Posta un commento
Non inserire link cliccabili altrimenti il commento verrà eliminato. Metti la spunta a Inviami notifiche per essere avvertito via email di nuovi commenti.