.dsy:it. - [PROGETTO] Database nativo Xml

Pages (2): [1] 2 »
Show 150 posts per page

.dsy:it. (http://www.dsy.it/forum/)
- Tech (http://www.dsy.it/forum/forumdisplay.php?forumid=189)
-- [PROGETTO] Database nativo Xml (http://www.dsy.it/forum/showthread.php?threadid=20135)

Posted by ripe on 14-06-2005 10:29:

[PROGETTO] Database nativo Xml

E' un pò di tempo che ho intenzione di iniziare un progetto di realizzazione di un database nativo in Xml, da utilizzare come contenitore dei dati per una classe di applicazioni CMS e PMS per il Web. Ora, ho osservato le API Open Source dell'Xml:db Project, e ne ho raccolto qualche informazione. Ho osservato i prodotti già esistenti (non molti a dire il vero) e ho constatato che la loro complessità è nettamente superiore a quanto avrei bisogno io.

Punti chiave:
- deve contenere solo testo... gli oggetti binari sono conservati solo come riferimenti nel filesystem
- deve permettere query di ogni tipo (selezione, inserzione, aggiornamento, cancellazione) utilizzando l'SQL o qualcuno di quei linguaggi in via di standardizzazione da parte del W3 (XQuery, XUpdate)
- deve essere installabile facilmente in una cartella che abbia permessi di scrittura e lettura, ed essere implementato in maniera gerarchica nel filesystem

Punti secondari:
- le prestazioni non sono più di tanto importanti
- concetti avanzati dei database possono essere aggiunti in un secondo momento (indicizzazione, clustering, transazioni, rollback...)

Domande:
- quale potrebbe essere la differenza in termini di prestazioni rispetto ad un database tradizionale tipo Access?!

Mi interessano tutti i vostri suggerimenti, aiuti, consigli...

Grazie e ciao!

__________________
«And if you ever smell christian blood up in the mountains, then get your axe and chop them down!»

Posted by AlphaGamma on 15-06-2005 14:55:

Progetto interessante.
Penso che l'integrità referenziale sia tuttavia una caratteristica da implementare sin da subito, così come alcune delle proprietà acide.

Access è molto lento. Su un DB di 30 mega e tabelle di un migliaio di record, tende ad impiegare tempi, in locale, pari a 30 secondi o più.
Non oso immaginare cosa potrebbe fare da remoto.

Per migliorare l'efficienza indubbiamente servono meccanismi di cache delle query, quindi fogli xml temporanei.

Certo è che la prospettiva di inserire db in xml in qualsiasi spazio web, senza dover gestire anche un db server, è davvero interessante.

__________________
Attenzio', concentrazio', ritmo e VITALITÀ

Posted by ripe on 15-06-2005 17:09:

Penso infatti che integrità referenziale e indicizzazione siano da inserire subito, in effetti...

Mi interessa una stima delle prestazioni relative all'accesso dei file che conterranno l'xml rispetto al motore di un database lento come Access... e poi, banalmente: ogni tabella deve essere rappresentata da un singolo file aggiornato continuamente, oppure deve essere splittata in un file per ogni record?

La parte concettuale mi sta devastando da un paio di giorni...

__________________
«And if you ever smell christian blood up in the mountains, then get your axe and chop them down!»

Posted by AlphaGamma on 16-06-2005 09:32:

Secondo me ti conviene fare delle prove.
Comunque se gestisci una specie di commit, potresti usare un solo foglio temporaneo con tutte le scritture, e dopo appunto questa commit, aggiornare le tabelle vere e proprie.

__________________
Attenzio', concentrazio', ritmo e VITALITÀ

Posted by ripe on 16-06-2005 09:37:

Allora, mi sto mettendo ora a scrivere... la scelta è ricaduta sul framework .NET che, a parte il livello di conoscenza mia, mi fornisce già tutti gli strumenti che ho bisogno e mi semplificherà di molto il lavoro!

L'idea è quella di creare un provider ereditando dall'interfaccia IDbProvider (quella base di OleDbProvider, OracleProvider, SqlProvider....), di riempire un DataSet con i dati del documento Xml (che dev'essere well-formed) e di manipolarli tramite le proprietà di questo potentissimo oggetto, che tra l'altro mi permette di supportare le transazioni grazie al metodo RejectChanges...

Dopodiché ho intenzione di realizzare quattro parser per supportare l'SQL nella sua forma classica: SELECT, INSERT, UPDATE, DELETE. E qui impazzirò! :asd:

Infine controllerò le prestazioni rispetto ad un database lento come Access (non voglio certo competere con MySql ).

Ora, al lavoro!

__________________
«And if you ever smell christian blood up in the mountains, then get your axe and chop them down!»

Posted by ripe on 16-06-2005 09:38:

Originally posted by AlphaGamma
Secondo me ti conviene fare delle prove.
Comunque se gestisci una specie di commit, potresti usare un solo foglio temporaneo con tutte le scritture, e dopo appunto questa commit, aggiornare le tabelle vere e proprie.

Questa è un'idea niente male, vediamo come reagisce l'oggetto DataSet (che è un pò lento) e in caso proverò anche questa interessante strada.... :approved:

__________________
«And if you ever smell christian blood up in the mountains, then get your axe and chop them down!»

Posted by ripe on 16-06-2005 09:48:

Per chi fosse interessato ad approfondire, qui si trova la lista completa delle interfacce che è necessario implementare per creare un provider di dati completo:

http://msdn.microsoft.com/library/d...lementation.asp

__________________
«And if you ever smell christian blood up in the mountains, then get your axe and chop them down!»

Posted by ripe on 16-06-2005 13:22:

I primi risultati!!!

Ho scritto la classe XmlDbConnection implementando IDbConnection e lasciando in sospeso tutti quei metodi che si occupano di transazioni e comandi Sql. Mi sono occupato solo della lettura del file e del mantenimento dello stato della connessione... poi ho provato la reazione dell'oggetto DataSet su un semplice file Xml (trovato in rete) ben formato:

code:
<?xml version="1.0"?>
 
<impiegati> 
 <impiegato id="M.R">
  <nome>Mario Rossi</nome>
  <email>mrossi@foo.com</email>
 </impiegato>
 <impiegato id="F.B">
  <nome>Filippo Bianchi</nome>
  <email>fbaldi@foo.com</email>
 </impiegato>
 <impiegato id="A.V">
  <nome>Alice Verdi</nome>
  <email>averdi@foo.com</email>
 </impiegato> 
</impiegati>

Poi ho chiesto all'oggetto DataSet di restituirmi il suo nome, l'elenco delle tabelle e l'elenco delle colonne per ogni tabella, e il risultato è stato questo:

code:
DataSet: impiegati
Table: impiegato
- Column: nome
- Column: email
- Column: id

Come inizio non c'è male, almeno sono riuscito a capire che struttura dovrebbe avere il database! :approved:

__________________
«And if you ever smell christian blood up in the mountains, then get your axe and chop them down!»

Posted by AlphaGamma on 16-06-2005 13:39:

Non ho capito bene come gestisci oggetti binari (immagino link su filesystem, oppure un foglio xml con dati in mime64?) e relazioni (id numerico?). Caspita cmq progettare da zero un db è complesso, senza dubbio...

__________________
Attenzio', concentrazio', ritmo e VITALITÀ

Posted by ripe on 17-06-2005 10:53:

Originally posted by AlphaGamma
Non ho capito bene come gestisci oggetti binari (immagino link su filesystem, oppure un foglio xml con dati in mime64?) e relazioni (id numerico?). Caspita cmq progettare da zero un db è complesso, senza dubbio...

Già...

Gli oggetti binari vorrei tenerli solo come riferimenti su filesystem per ora, poi si vedrà... per quanto riguarda le relazioni vorrei cercare se esiste qualcosa di insito nel modello XmlSchema, altrimenti ci penserò più avanti...

Nel frattempo ho implementato le transazioni: ora il DataSet è in grado di fare Commit accettando le modifiche e salvando il database nel file originale, oppure di rifiutare le modifiche durante un Dispose e di tornare allo stato precedente con un RollBack!

Il problema più grande mi sa che saranno le prestazioni, non eccezionali. A quanto ho letto in rete, oltre i 3000 record peggiorano in maniera nettissima. Comunque poi farò delle prove approfondite, con o senza XmlSchema e vedrò il da farsi. Potrei obbligare ad utilizzare lo schema, per evitare l'inferenza della struttura che occupa molte risorse. Boh!

__________________
«And if you ever smell christian blood up in the mountains, then get your axe and chop them down!»

Posted by ripe on 17-06-2005 16:32:

Sto impazzendoooooooooooooo... :twisted:

L'unico modo per fargli riconoscere correttamente l'Xml in ingresso è di formulare uno schema Xsd precedentemente (cosa peraltro intuibile). E anche in questo caso le relazioni tra le tabelle sono curiose...

Ma chi me l'ha fatto fare!? :asd:

__________________
«And if you ever smell christian blood up in the mountains, then get your axe and chop them down!»

Posted by yeah on 17-06-2005 20:00:

L'idea non è male... ma da quello che ho letto qui e da quel poco che so, direi che il tutto richiede un programma su server, oppure funziona da pagine (ASP?) normali?

__________________
?

Posted by ripe on 18-06-2005 08:53:

No, nessun programma su server... è proprio quello il bello dell'Xml!
Basta copiare il tuo database in una cartella con permessi di lettura/scrittura... con Asp.Net poi devi incollare la .dll generata in fase di compilazione nella cartella "bin" e sei pronto per istanziare gli oggetti necessari alla connessione...

Ieri poi, prima di scappare a bere alla Festa dell'Unità, ho ultimato l'oggetto Command che, in piena tradizione ADO.NET, può eseguire un lettore di dati, delle query di inserzione/aggiornamento/cancellazione e la semplice ricerca di uno scalare. Oggi arriva il difficile: implementare il cursore che legga effettivamente i dati dalle tabelle lette, considerando anche implicite le relazioni tra le tabelle annidate!

__________________
«And if you ever smell christian blood up in the mountains, then get your axe and chop them down!»

Posted by yeah on 18-06-2005 12:57:

Basta copiare il tuo database in una cartella con permessi di lettura/scrittura... con Asp.Net poi devi incollare la .dll generata in fase di compilazione nella cartella "bin" e sei pronto per istanziare gli oggetti necessari alla connessione...

Ah quindi sarebbe ASP-dipendente, giusto?

__________________
?

Posted by ripe on 18-06-2005 13:07:

Si, ma non Windows o IIS dipendente, visto che con Mono si può far girare Asp.Net anche su Linux e Apache!

__________________
«And if you ever smell christian blood up in the mountains, then get your axe and chop them down!»

All times are GMT. The time now is 23:16.

Pages (2): [1] 2 »
Show all 25 posts from this thread on one page