 | |
Il progetto dsy.it è l'unofficial support site dei corsi di laurea del Dipartimento di Scienze dell'Informazione e del Dipartimento di Informatica e Comunicazione della Statale di Milano. E' un servizio degli studenti per gli studenti, curato in modo no-profit da un gruppo di essi. I nostri servizi comprendono aree di discussione per ogni Corso di Laurea, un'area download per lo scambio file, una raccolta di link e un motore di ricerca, il supporto agli studenti lavoratori, il forum hosting per Professori e studenti, i blog, e molto altro...
In questa sezione è indicizzato in textonly il contenuto del nostro forum |
[PROGETTO] Database nativo Xml
Clicca QUI per vedere il messaggio nel forum |
| ripe |
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! |
| AlphaGamma |
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. |
| ripe |
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... :D |
| 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. |
| ripe |
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 :D ).
Ora, al lavoro! |
| ripe |
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: |
| ripe |
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: |
| 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... |
| ripe |
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! |
| ripe |
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: |
| yeah |
| 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? |
| ripe |
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! |
| yeah |
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? |
| ripe |
| Si, ma non Windows o IIS dipendente, visto che con Mono si può far girare Asp.Net anche su Linux e Apache! ;) |
| yeah |
Già è vero :)
E' solo che leggendo mi era venuto in mente un equivalente in PHP, da cui il dubbio sul programma lato server :) |
| ripe |
Non so sinceramente se esista un equivalente in Php, anzi... se qualcuno mi desse qualche riferimento ne sarei molto contento! :)
Intanto scrivere il parser Sql si sta rivelando più divertente del previsto. Per ora riconosce solo l'istruzione SELECT con le clausole basilari, però cresce... :D |
| ripe |
| Le query del tipo SELECT...FROM...WHERE sono completamente riconosciute, domani sarà il giorno decisivo. Prenderò un file Xml già popolato ed utilizzerò l'oggetto Command per eseguire una query. Se il DataAdapter mi restituirà tutti i record coinvolti bene, altrimenti vedrò il da farsi... |
| yeah |
| Forse mi è sfuggito :D ma come controlli e assicuri la concorrenza? |
| ripe |
Per ora non è una priorità... verrebbe utilizzato in ambienti ad accesso singolo o con un basso livello di multiutenza...
Ricapitolando:
- l'istruzione Select funziona
- l'istruzione Insert funziona
- l'istruzione Update funziona
- l'istruzione Delete non è ancora stata provata
Prossimo obiettivo:
Join automatico su più tabelle! |
| yeah |
Per ora non è una priorità... verrebbe utilizzato in ambienti ad accesso singolo o con un basso livello di multiutenza...
Ah ok :) Pensavo fosse per un sito web pubblico |
| ripe |
Originally posted by yeah
Ah ok :) Pensavo fosse per un sito web pubblico
Si, ma l'accesso multiplo non è un problema... è l'aggiornamento dei dati che importa ai fini della concorrenza... o mi sono perso qualcosa?
Se hai qualche suggerimento è ben accetto, non me ne intendo molto si quest'argomento! ;) |
| yeah |
Si, ma l'accesso multiplo non è un problema... è l'aggiornamento dei dati che importa ai fini della concorrenza... o mi sono perso qualcosa?
Assolutamente no (tralasciando le transazioni) :) E' solo che hai detto che hai implementato insert, update e delete, da cui la domanda :)
A meno che quelle query vengono fatte in via 'speciale' solo dall'amministratore, il che ne semplifica di molto la gestione.
In questo caso servizi quali forum & co non sarebbero però possibili.
In una parola dipende da cosa (e a quale livello) vuoi ottenere |
| ripe |
Originally posted by yeah
Assolutamente no (tralasciando le transazioni) :) E' solo che hai detto che hai implementato insert, update e delete, da cui la domanda :)
A meno che quelle query vengono fatte in via 'speciale' solo dall'amministratore, il che ne semplifica di molto la gestione.
In questo caso servizi quali forum & co non sarebbero però possibili.
In una parola dipende da cosa (e a quale livello) vuoi ottenere
Grande, in effetti c'è da riflettere su questa cosa....! :approved: |
|
|
|
|
