Database documentali
Ciao
Da qualche mese sto lavorando con un database documentale molto simile a MongoDb, si chiama LiteDb (http://www.litedb.org/)
In rete si trova poca roba in giro e vorrei capire i meccanismi di query di questi db documentali o meglio ancora le best practices per strutturare un db al fine di sviluppare una applicazione.
So che è una domanda un tantino generica ma potrebbe essere un inizio per aprire una o più discussioni.
Qualcuno ha qualche esperienza in merito?
Mi piacerebbe capire cosa si intende con Database Documentale e come tale database viene "riempito" con i documenti.
Dal nome intuisco che vi si inseriscano dei documenti, ma che tipo di documenti? e quale è l'obiettivo dell'uso di uno di questi database.
Ho sentito parlare di MongoDB ma non ho mai avuto occasione di lavorarvi quindi per me è semplicemente una scatola con un nome.
Ho guardato la pagina di documentazione sulla Select di LiteDb ma fatto salvo parlare di Json, non sembra molto diverso da una normale query sui dati.
Pertanto se hai tempo di darmi qualche lume su come funziona il db, poi possiamo capire.
Felice di risponderti.
Un documento non e' niente altro che un file Bson ovvero un Binary Json (https://it.wikipedia.org/wiki/BSON)
Di fatto e' un json, ciò significa che e' facilmente editabile anche con un text editor.
La sua peculiarità e' che può gestire dati in struttura gerarchica. Ed è quindi un formato molto comodo, semplice e leggero per scambiare dati in formato testuale.
Json ormai e' onnipresente nel web e consumabile con qualsiasi linguaggio di programmazione moderno.
Questo è un esempio testuale di un json (vi invito a fare un prettify qui: https://jsonformatter.org/ per leggerlo meglio)
{"_id":{"$oid":"5f5b642ef1104053c0dd0701"},"_docName":"Persona","Nome":"enter string","Cognome":"enter string","DataDiNascita":{"$date":"2020-09-11T11:49:51.9510000Z"},"Indirizzi":{"Casa":{"Via":"enter string","Cap":"enter string","Città":"enter string"},"Ufficio":{"Via":"enter string","Cap":"enter string","Città":"enter string"}}}
Newtonsoft ma anche altri, hanno realizzato delle librerie per serializzare e deserializzare oggetti in formato json.
Questo significa che se io avessi una classe persona e la serializzassi in un file json, otterrei il risultato di cui sopra.
Ovviamente possono essere gestiti svariati tipi di dato, int32, 64, datetime, bool, array e anche document ovvero un documento può contenere un altro documento.
Infatti nell'esempio sopra, Casa e Ufficio sono due documenti contenuti in un documento padre Indirizzi, contenuto a sua volta in un documento padre Persona
I subdocumenti possono essere anche dei link verso altri documenti contenuti in collezioni diverse.
I documenti poi sono "banalmente" archiviati dentro a delle collezioni.
Le collezioni sono "banalmente" archiviate nei Db .
La logica e' molto semplice ed immediata.
Nel nostro caso, in un db relazionale avremmo una tabella persone (Persona sarebbe un record) e una tabella indirizzi (con due record Casa e Ufficio che poi sarebbero relazionati a Persona).
Mi piace quindi pensare, che un json sia di fatto una tabella gerarchica, o multidimensionale proprio perché può annidare innumerevoli livelli di dati).
Ne consegue che, sebbene sia semplicissimo archiviare dei dati, e' un po' più difficile (forse solo per me) capire i meccanismi di query in quanto potrei interrogare un singolo documento enorme (e ce ne sono) oppure tutti i documenti contenuti in una collezione.
LiteDb ha il suo linguaggio di query simil Linq ed un linguaggio SQL-Like che viene poi parsato.
MongoDb per quanto mi risulti ha un linguaggio simil Linq e basta.
Esistono poi altri db documentali (https://it.wikipedia.org/wiki/Base_di_dati_orientata_al_documento) ed ognuno ha il suo linguaggio di query.
Quindi, per strutturare correttamente una base dati, bisognerebbe capire anche quale sia il miglior approccio per poi interrogarla.
In ambito relazionale sono state scritte galassie di libri ma in ambito documentale fatico a trovare delle best practices o comunque dei buoni esempi.
LiteDb e' un prodotto open e giovane, in cui credo, ma la documentazione e' molto scarsa e bisogna procedere un po' per tentativi.
Di mio ho realizzato in C# e WPF un frontend per poter gestire i db di LiteDb, e' ancora in beta ma funziona tutto sommato bene.
Le query si possono eseguire ma non conosco ancora correttamente tutta la sintassi e tutte le possibilità che ne derivano.
In alcuni casi non sono ancora riuscito a ottenere dalle query gli output che desidero, proprio perché la documentazione è ancora scarsa e non so come scriverle.
Sempre con LiteDB ho realizzato un semplice PasswordManager che uso tutti i giorni 🙂
Mmmh... Avendo iniziato a programmare quando il massimo dei database relazionali era DB3, ed avendo proseguito per una decina d'anni con CTree (i record sequenziali binari in cui io ero responsabile di gestirne la lettura in base alla lunghezza delle strutture dati), per poi passare ai relazionali, dove mi sono scontrata con il fatto che non potevo creare gli array all'interno dei record, ma ho imparato che in quei casi bisogna creare una tabella relazionata, mi riconosco poco orientata al genere di DB che tu utilizzi. Ma temo sia un limite dovuto all'Età...
Ciò premesso, un database relazionale, normale o liquido può essere ricercato in modo arbitrario con l'uso di una FullTextSearch, SqlServer ne ha una fatta molto bene in questo senso.
Ho capito la forma del tuo database documentale ed il suo uso, io ho recentemente lavorato su una applicazione che utilizza un albero per rappresentare dati complessi e anche in questo caso, in un relazionale non è stato poi così complicato creare l'oggetto, ed anche in questo caso, la ricerca si fa utilizzando una FullTextSearch il cui catalogo viene generato a partire da tutti gli oggetti che si vogliono indicizzare, gli oggetti sanno a che foglia sono collegati, le foglie sanno a che ramo sono collegate ed i rami a quale altro ramo o albero e quindi è semplice trovare le cose e mostrarle agli utenti.
Nel caso del tuo Database BSon credo che dovresti verificare se ha un motore di ricerca fulltext e come fare a generarne il catalogo oppure se può essere agganciato a qualche tipo di search engine come ad esempio ElasticSearch che costruisce il catalogo e ti permetta di creare una interfaccia per la ricerca dei dati in modo organizzato ed user friendly.
Ti garantisco che la parte di interfaccia più complicata che abbiamo generato e le classi dati più complesse, nella mia applicazione sono quelle che gestiscono le ricerche dati, per dare agli utenti modo di cercare i dati in ogni modo possibile.
Saluti
LiteDb ad oggi non implementa il FullTextSearch e nemmeno query geospaziali.
Sono features da implementare a parte con altri strumenti se uno vuole.
Non e' detto che in futuro non siano implementate. Come dicevo e' un prodotto open relativamente giovane.
E' comunque pensato come un SQLite documentale. Quindi non esiste nemmeno una parte server sempre per ora.
Le query si possono risolvere facilmente con Linq. Quindi pero' via codice e non in maniera "liquida".
Per il linguaggio SQL-Like ovviamente serve un parser da testo a query Linq, che di fatto già esiste ma che non implementa ancora tutte le funzioni che uno si aspetta.
Come dici tu, la parte piu' complessa e' la ricerca delle informazioni ma è anche la piu' importante. I dati non basta salvarli, bisogna anche interrogarli e poi valutarli. Saperli valutare poi e' un altro mestiere 😉