SqLite vs Access vs Sql Ce 3.5

Andrea Zani — Sat, 24 Oct 2009 19:23:34 GMT

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�.

Tags: .NET Framework, ADO.NET, ASP.NET, Database, SQL Server

Continua a leggere SqLite vs Access vs Sql Ce 3.5.

Query ricorsive con sql server 2005

Andrea Zani — Sat, 05 May 2007 15:36:00 GMT

Me lo segno.

Stare troppo su Sql server nella versione 2000 ti fa perdere di vista le novit� del pi� potente 2005. Eccomi dunque a segnarmi una memo sul modo pi� veloce e prestazionale per eseguire una query ricorsiva sul mio blog.

A che serve una query ricorsiva? La risposta pi� semplice � nel caso della struttura ad albero memorizzato in una tabella il poter avere tutti i figli di un determinato ramo. Ecco il caso di una tabella:

id	id_padre	nome
1	0	a
2	1	aa
3	1	ab
4	2	aaa
5	2	aab
6	4	aaaa
7	3	aba
8	3	abb
9	7	abaa

L'albero � semplice, il padre � "a", e i figli seguono l'ordine alfabetico. Ora, se volessi sapere tutti i figli e nipoti di aa, con sql server 2005, posso scrivere:

with tree(id,id_padre,nome) as
(
select id,id_padre,nome from albero where id=2 -- id del padre
union all
select a.id,a.id_padre,a.nome from albero a
inner join tree t on t.id=a.id_padre
)
select�id,id_padre,nome from tree

Molto pi� semplice e veloce che la costruzione di una funzione apposita...

Tags: Database, SQL Server

Continua a leggere Query ricorsive con sql server 2005.

blogs.ASPItalia.com

SqLite vs Access vs Sql Ce 3.5

Query ricorsive con sql server 2005