Per riprendere confidenza alla programmazione dopo un periodo di riposo forzato, ho messo mano in questi giorni al mio sito per ottimizzare il codice e per nuove implementazioni che da troppo tempo erano in cantiere. A parte la primissima versione del sito che era fatta completamente in html senza nessun supporto server side, nella sua implementazione prima con il classic asp e poi con asp.net, si è sempre basato sul database Access. Tuttora sono due i database che tengono in piedi il tutto senza grosse fatiche e il minimo uso di cache presente ha permesso che non ci fossero rallentamenti e problemi dovuto ad un uso massiccio di questo tipo di database.

Proprio durante la fase di sviluppo di questi giorni è nata l'idea di prendere in considerazione anche altri database. Innanzitutto, essendo il sito su un hosting povero, non ho a disposizione database degni di questo nome come Sql Server o MySql, e arrangiarsi alla bell'e meglio è ciò che mi ha obbligato a guardarmi attorno alla ricerca di alternative e, perché no, mi ha permesso di prendere confidenza con qualcosa di nuovo. Pensandoci bene, a parte la mia esigenza personale dettata dal mio sito e viste le alternative possibili, è proprio obbligatorio passare ad hosting più costosi per siti con basso traffico solo per avere un database serio quando il numero di richieste pagine/query è talmente basso da far apparire addirittura sprecato un hosting con Sql Server o MySql? In fondo, se uno prende uno spazio di hosting per inserire un proprio blog o come contenitore di informazioni personali, dunque con una previsione almeno iniziale di carico molto basso, anche Access può far degnamente il suo lavoro. Ma perché non prendere in considerazione anche altre alternative?

In questo blog voglio solo trascrivere le mie sensazione nell'uso e di test personali nell'uso di tre database utilizzabili nelle proprie medio piccole web application:

• Access
• SqLite
• Sql CE

Access per i più non ha bisogno di presentazione. Prima o poi lo incontrano tutti nel loro percorso informatico. Probabilmente il più facile database disponibile ed è facilmente utilizzare fin dai tempi del classic asp: è sufficiente prendere il file del database (.mdb) e copiarlo in una directory sul server, e senza alcun'altra installazione sul server, si può interrogare da codice con poche righe di codice. I suoi difetti maggiori sono le prestazioni e l'impossibilità di usarlo in multiutenza. Per le web application il problema maggiore rimane solo il primo visto che se in lettura molte pagine possono accedere contemporaneamente, in scrittura solo un'operazione alla volta è possibile.

La connessione, avviene grazie ai driver ole-db, e il Framework mette a disosizione un namespace apposito: System.Data.OleDb, con tutta la sua sequenza di classi:

• OleDbConnection
• OleDbCommand
• OleDbDataAdapter
• OleDbDataReader
• ...

E utilizzare questa stringa di connessione: "Provider=Microsoft.Jet.OLEDB.4.0;Data source=database.mdb":

OleDbConnection conn=new OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data source=database.mdb");

SqLite è un progetto completamente free e può essere utilizzato per qualsiasi tipo di applicazione. Per utilizzarlo nelle proprio web application in asp.net, è sufficiente copiare il file System.Data.SQLite.dll nella directory bin (o creando una refernce da Visual Studio). Come Access, anche questo database di basa su un file che ha come suffisso ".s3db". Per creare questo database sono presenti numerosi progetti free, io ho utilizzato il famoso SqLite Administrator:

SqLite per il framework è possibile scaricarlo da questo link. Una volta installato è possibile trovare i file di nostro interesse nella directory:

C:\Programmi\SQLite.NET\bin

Oltre alle dll possiamo trovare anche un test di esempio per l'utilizzo di questo database e la documentazione. Inoltre possiamo integrare il designer di SqLite direttamente in Visual Studio e con Linq.

SqLite è utilizzabile dai progetti scritti con il Framework dal namespace System.Data.SQLite che mette a dispozione le classi apposite:

• SqLiteConnection
• SqLiteCommand
• SqLiteDataAdapter
• SqLiteDataReader
• ...

La stringa di connessione è "Data Source=database.s3db". Per esempio:

SqLiteConnection conn=new SqLiteConnection("Data Source="+Request.MapPath("database.s3db"));

Anche se non rientra nei canoni dell'obbiettivo di questo blog ho preso in considerazione anche Sql CE di Microsoft. Se si utilizza per lo sviluppo Visual Studio, probabilmente lo si ritroverà all'interno della propria macchina. Altrimenti è possibile scaricarlo gratuitamente da questo link. La creazione e la gestione delle tabelle è molto semplice visto che è possibile manipolare i file di database di Sql CE (con suffisso ".sdf") con gli editor di Sql Server, o con il gratuito Microsoft SQL Server Management Studio Express. Qui sotto la banale operazione di creazione di un database di questo tipo con il Sql Server Managment Studio della versione 2008:

Come scritto sopra, non rientra nei canoni della mia valutazione perché per inserire questo tipo di database su un server in hosting per la propria web application, non è sufficiente copiare le dll ma deve essere installato direttamente sulla macchina. A queste conclusioni sono giunto dopo numerosi tentativi andati a vuoto e dopo una veloce ricerca in rete di una soluzione. Se qualcuno sa una strada che può portare alla soluzione è benvenuta qualsiasi informazioni in merito.

Inserita la reference a "System.Data.SqlServerCe" nella web application abbiamo il namespace apposito e le classi per la manipolazione di questo database:

• SqlCeConnection
• SqlCeCommand
• SqlCeDataAdapter
• SqlCeDataReader
• ...

La stringa di connessione è uguale a quella che per SqLite: "Data Source=database.sdf". Per esempio:

SqlCeConnection conn=new SqlCeConnection("Data Source="+Request.MapPath("database.sdf"));

Se si prova ad utilizzare Sql CE in una web application si ha inizialmente una sorpresa trovandosi di fronte all'errore:

"SQL Server Compact Edition is not intended for ASP.NET development"

La soluzione si basa nell'aggiunta di questo riga di codice:

AppDomain.CurrentDomain.SetData("SQLServerCompactEditionUnderWebHosting", true);

Per i miei test ho utilizzato due semplici tabelle con una relation, aventi questa struttura:

FirstName e Information sono campi varchar, Age è un campo numerico così come ParentId che lega i record della tabella "Table2" ai record presenti in "Table1". Il test si basa sulla scrittura di centiana di record alla volta e a delle query di lettura su questi record in modo ripetuto.

Il primo test si basa sulla scrittura di dieci record nella prima tabella e di trenta nella seconda. Oltre la scrittura, dopo l'inserimento della prima tabella, viene letto l'Id generato dalla tabella per creare il giusto riferimento nella tabella figlia. Qui sotto riporto i tre database:

N. tentativi	Access	SqLite	SqLite - T	Sql CE 3.5
1°	0s 93	8s 53	0s 40	0s 73
2°	0s 98	8s 25	0s 47	0s 74
3°	0s 93	8s 70	0s 46	0s 71

Ho dovuto inserire in due colonne i tempi di SqLite a causa delle prestazioni scadenti di questo database se non utilizziamo procedure apposite per questo tipo di operazione. Il codice di test per l'inserimento di tutti i database si basa su un banale ciclo for. All'interno di esso eseguo l'apertura della connessione del database, quindi una a una le singole operazioni di scrittura. Pressappoco questo schema:

for (int i=0;i<10;i++)
{
// Apri connessione
// Esegue inserimento in tabella 1
// Legge l'ID inserito dal database per l'inserimento
for (int x=0;x<30;x++)
{
// Inserisce record nella tabella 2
}
// Chiude connessione
}

Grazie a questo codice ci si scontra ad un grosso limite di SqLite che, nelle operazioni di grande inserimento, si scontra con un crollo di prestazioni notevole. Per evitare questo problema, è sufficiente mettere le varie fasi di inserimento in transaction per avere quel balzo di prestazioni che lo porta al primo posto nella tabella precedente (colonna "SqLite - T"). Il codice qui sopra va riscritto in questo modo:

for (int i=0;i<10;i++)
{
// Apri connessione
// Apri transaction (invio comando "begin")
// Esegue inserimento in tabella 1
// Legge l'ID inserito dal database per l'inserimento
for (int x=0;x<30;x++)
{
// Inserisce record nella tabella 2
}
// Chiususa transaction (invio comando "commit")
// Chiude connessione
}

Anche se i distacchi sono limitati, Access risulta il più lento e SqLite il più veloce anche se, abbiamo dovuto ottimizzare il codice appositamente per lui. Di seguito ho eseguito delle operazioni ripetute in lettura. Le tabelle, composte da trenta record la prima e novecento la seconda, vengono lette la prima per n volte, e la seconda viene conteggiata in una query il numero di record. I risultati sono i seguenti:

N. tentativi	Access	SqLite	Sql CE 3.5
1°	2s 49	0s 31	1s 33
2°	2s 34	0s 23	1s 25
3°	2s 35	0s 23	1s 26

Qui non c'è storia: SqLite fa la differenza. Access è l'ultimo con distacchi abissali. L'ultimo test di lettura esegue ripetute query con join tra le due tabelle.

N. tentativi	Access	SqLite	Sql CE 3.5
1°	3s 88	0s 96	2s 55
2°	3s 99	0s 97	2s 55
3°	3s 91	0s 96	2s 67

Si possono tirare delle conclusioni? No. Anche se l'informatica si avvicina moltissimo alla matematica è soggetta alla regola che vige in politica e sport dove chiunque può dire il contrario di tutto solo per partito preso. E siccome a me non me ne frega nulla e so che là fuori c'è sempre qualcuno che si sente il diritto di criticare, ognuno tiri le conclusioni per sé. Anzi, consiglio di fare delle prove e valutare. Le banderuole si muovono a seconda di dove tira il vento, e non hanno cervello. Altri lo hanno, deturpato o meno, ma è più comodo sventolare per simpatie personali.

E siccome non me ne frega nulla - questa frase non varrebbe nulla se non dessi un mio parere personale, perché se non lo facessi vorrebbe dire che mi importerebbe - ecco un mio giudizio: SqLite è leggero ed ha ottime prestazioni, lo prenderei in considerazione per piccole web application tenendo sempre d'occhio le varie ottimizzazioni per evitare inconvenienti come quello della scrittura che ho citato. Access si può definire finito nelle web application? Nì: le alternative ci sono e se si vuole dirla tutta, se proprio si vuole un database degno di tal nome perché si prevedono necessità pesanti, senza dover andare su Sql Server, ormai tutti i servizi di hosting anche economico danno MySql con un piccolo sovrapprezzo. L'importante è sapere che sino alternative. In ogni caso rimando per approfondimenti sui vari database che ho trattato alla numerosa documentazione che è reperibile in Internet - se con questo mio blog ho acceso un po' la curiosità.