Le best practice per accedere ai dati senza schema?

Question

Mi sto giocando con RDF, e in particolare come accedere alle informazioni memorizzate in un archivio rdf. L'enorme differenza da un database relazionale tradizionale è la mancanza di uno schema predefinito: in un database relazionale, sai che la tabella ha quelle colonne e puoi tecnicamente mappare ogni riga a un'istanza di una classe. La classe ha metodi ben definiti e attributi ben definiti.

In un sistema senza schema, non si conoscono i dati associati a una determinata informazione. È come avere una tabella di database con un numero arbitrario e non predefinito di colonne e ogni riga può contenere dati in un numero qualsiasi di queste colonne.

Analogamente agli ObjectRelational Mapper, esistono i programmi di mappatura degli oggetti RDF. RDFAlchemy e SuRF sono i due che sto suonando in questo momento. Fondamentalmente, ti forniscono un oggetto risorsa, i cui metodi e attributi sono forniti dinamicamente. Ha un certo senso ... tuttavia, non è così facile. In molti casi, preferisci avere un'interfaccia ben definita e avere un maggiore controllo su ciò che accade quando imposti e ottieni dati sul tuo oggetto modello. Avere un accesso così generico rende le cose difficili, in un certo senso.

Un'altra cosa (e più importante) ho notato è che, anche se ingenere, dati dello schema-less sono tenuti a fornire informazioni arbitrario su una risorsa, in pratica più o meno sapere "classi di informazioni "che tendono ad essere insieme. Naturalmente, non è possibile escludere la presenza di informazioni aggiuntive, ma questo, in alcuni casi, è l'eccezione, piuttosto che la norma, sebbene l'eccezione sia abbastanza ragionevole da risultare troppo dirompente per uno schema rigido. In una rappresentazione rdf di un articolo (ad esempio, come nei feed RSS/ATOM), conosci i termini delle risorse descritte e puoi associarli a un oggetto ben definito. Se fornisci informazioni aggiuntive, puoi definire un oggetto esteso (ereditato da quello di base) per fornire accessor alle informazioni avanzate. Quindi, in un certo senso, si gestiscono i dati senza schema per mezzo di "oggetti orientati allo schema" è possibile estendere quando si desidera visualizzare le informazioni aggiuntive specifiche di cui si è interessati al numero.

La mia domanda è relativa alla tua esperienza sulle pratiche di utilizzo del mondo reale dell'archiviazione dei dati senza schema. In che modo si mappano al mondo orientato agli oggetti in modo tale da poterlo usare con competenza e senza avvicinarsi troppo al "bare metal" dello storage senza schema? (in termini RelDB, senza usare troppo SQL e incasinando direttamente la struttura della tabella)

L'accesso è destinato ad essere molto generico (ad es. SuRF "attributi plug-in" è il livello più alto e più specializzato che si possa avere accedere ai dati) o avere classi specializzate per specifici schemi concordati è anche un buon approccio, introducendo tuttavia il rischio di avere una proliferazione di classi per accedere a dati associati nuovi e inattesi?

Answer 1

Suppongo che la mia risposta breve sarebbe "non farlo". Sono un po 'barbuto e ho eseguito molti mapping di dati XML in database relazionali. Se decidi di utilizzare tale database, dovrai convalidare i tuoi dati costantemente. Avrai anche bisogno di una disciplina molto severa per evitare di avere database con poca comunanza. L'utilizzo di uno schema aiuta qui, poiché la maggior parte degli schemi XML sono orientati agli oggetti e quindi estensibili, facilitando la necessità di analisi per evitare di creare dati simili con nomi diversi, il che farà sì che chiunque debba accedere al database possa pensare a pensieri malvagi su di te.

Nella mia esperienza personale, se stai facendo il genere di cose in cui un database in rete ha senso, provaci. In caso contrario, si perdono tutte le altre cose che i database relazionali possono fare, come il controllo dell'integrità, le transazioni e la selezione delle impostazioni. Tuttavia, poiché la maggior parte delle persone usa comunque un database relazionale come archivio di oggetti, suppongo che il punto sia discutibile.

Per quanto riguarda l'accesso ai dati, è sufficiente inserirli in un Hashtable. Sul serio. Se non c'è schema da nessuna parte, non saprai mai cosa c'è lì dentro. Se si dispone di uno schema, è possibile utilizzarlo per generare oggetti accessor, ma si guadagna poco, in quanto si perde tutta la flessibilità dell'archivio sottostante mentre contemporaneamente si ottiene l'inflessibilità di un DAO (Data Access Object).

Ad esempio, se si dispone di un Hashtable, ottenere i valori da un parser XML è spesso abbastanza semplice. Si definiscono i tipi di archiviazione che si intende utilizzare, quindi si cammina l'albero XML e si inseriscono i valori nei tipi di archiviazione, memorizzando i tipi in un Hashtable o in Elenco come appropriato. Se, invece, si utilizza un DAO, si finisce per non essere in grado di estendere banalmente l'oggetto di dati, uno dei punti di forza di XML, e si deve creare getter e setter per l'oggetto che fanno

public void setter(Element e) throws NoSuchElementException { 
    try { 
     this.Name = e.getChild("Name").getValue(); 
    } catch (Exception ex) { 
     throw new NoSuchElementException("Element not found for Name: "+ex.getMessage()); 
    } 
} 

Tranne , naturalmente, devi farlo per ogni singolo valore in quel livello schema, inclusi i caricatori e le definizioni per i sottolivelli. E, naturalmente, si finisce con un pasticcio molto più grande se si utilizzano i parser più veloci che impiegano i callback, poiché ora si deve tenere traccia di quale oggetto si trova mentre si produce l'albero risultante.

Ho fatto tutto questo, anche se normalmente costruisco un validatore, quindi un adattatore che fornisce la corrispondenza tra l'XML e la classe di dati, quindi un processo di riconciliazione per riconciliarlo al database. Quasi tutto il codice finisce per essere generato, però. Se si dispone della DTD, è possibile generare la maggior parte del codice Java per accedervi e farlo con prestazioni ragionevoli.

Alla fine, manterrò semplicemente dati freeform, in rete o gerarchici come dati freeform, in rete o gerarchici.

Answer 2

Non ho esperienza con lo schema less DB abbinato a OOP, con un anno di esperienza con uno schema meno DB e scripting. Dalla mia esperienza, può essere abbastanza utile. Anche il DB che ho usato non è stato tipizzato (tutte le stringhe arbitrarie). Ciò comporta i seguenti vantaggi:

• non devi preoccuparti della struttura del DB. Se hai bisogno di immagazzinare qualcosa, devi semplicemente salvarlo. E non devi preoccuparti dei tipi di dati che si adattano al linguaggio di scripting
• puoi facilmente aggiungere informazioni di debug a "oggetti" quando necessario senza avere colonne vuote per la maggior parte delle righe della tabella. Ciò consente di archiviare anche enormi blocchi di dati laddove necessario,
• non è necessario preoccuparsi degli aggiornamenti della struttura del DB. Basta scrivere sul database i nuovi dati forniti con la nuova versione del software.In questo modo, non è necessario un amministratore per aggiornare la struttura della tabella e convertire i vecchi dati. Succede solo al volo
• se la chiave per i vostri valori-chiave coppie ha un nome meaningfull, non è necessario molta documentazione per i dati

Quindi, nel mio caso, lo schema meno DB insieme lo scripting è stato molto utile e un enorme successo.

Quando si pensa di utilizzare gli oggetti per lo schema meno DB, proverei a mantenere la libertà archiviando gli oggetti in una tabella hash. Questo ti darebbe la libertà di accedere a tutte le coppie chiave-valore - non importa quale "oggetto" hai selezionato. Ti darebbe anche la libertà di aggiungere nuovi valori-chiave, se necessario.

Se i tuoi oggetti (come in un feed RSS) hanno una base ben definita, ha senso inventare un oggetto base che incapsula la base ben definita ma ha anche una sorta di mappa hash per la tua libertà.

Non appena scopri che sempre più coppie chiave-valore risultano essere "standard", basta aggiornare il modello dell'oggetto per incapsularle: il software si evolverà nella giusta struttura dati. Può essere sensato spostare alcuni dati su un RMDBS tradizionale in un secondo momento.

Non più di ingegnere - implementare le funzionalità quando necessario ...

Answer 3

direi che la migliore pratica per un file XML schema-meno è quello di creare uno schema per questo!

Non avere schemi non è particolarmente bello. Significa che non è possibile validare il file in alcun modo, se non per rilevare se si tratta di XML ben formato o meno.

Non avere alcuna semantica del file di alcun tipo. Perché ciò significherebbe che non sai cosa dovresti, hai fatto o ci metterei dentro. Se questo è il caso, suona sospettosamente come una soluzione in cerca di un problema.

Se non si dispone di uno schema perché non si conosce ancora un linguaggio dello schema, dare un'occhiata a DTD. È molto semplice Puoi imparare e padroneggiarlo in circa un'ora o due, se hai un'applicazione di validazione o un parser di convalida nella tua applicazione.

Se il problema che impedisce di avere uno schema è che le regole dello schema non sembrano adatte ai tipi di file di definizione dello schema visti finora, non temere.

Mentre i file DTD e anche XSD (XML Schema) sono piuttosto rigidi, esistono altri tipi di file di schemi più flessibili. Sono molto più semplici di XSD, fidati di me.

Dai un'occhiata alle specifiche del file di schema RNC (RELAX NG, compact). I file RNC sono molto facili da leggere e scrivere per gli umani. Là fuori ci sono alcuni editor XML che li capiscono. Ci sono programmi di utilità che convertiranno avanti e indietro tra il formato RELAX NG (RNG o RNC) e altri formati come DTD e XSD.

L'ultima volta che ho controllato, l'XHTML TR ha incluso un file RNC non normativo per aiutare a convalidarlo, per non parlare di documentarlo in modo inequivocabile. RELAX NG ha la flessibilità per farlo e puoi leggerlo senza far parte del collettivo Borg. In questo caso Borg non è un eufemismo di Microsoft.

Se avete bisogno di qualcosa di ancora più flessibile di RELAX NG, date uno sguardo allo Schematron. È un linguaggio di convalida dello schema molto valido basato su regole. Non è molto complesso. Come questi altri linguaggi dello schema, anche questo è in circolazione da molto tempo, è maturo ed è uno standard riconosciuto.

Anche alcuni ingegneri senior di Microsoft avevano gravi dubbi su XSD. La complessità è alta, risulta essere in grado di esprimere alcune disposizioni di dati non così bizzarre, è molto prolisso, mescola preoccupazioni come convalida e valori predefiniti e così via. Qualunque cosa tu stia facendo, non sembra molto adatto per sostenerlo direttamente.

I mapper RDF, come gli strumenti di collegamento XSD, sono adatti per oggetti persistenti, date le loro classi in alcuni linguaggi di programmazione supportati come Java (ad esempio con JAXB). In ogni caso, non è chiaro se tu abbia alcune classi che vuoi perseverare.

Ci sono alcune tecnologie web semantiche come OWL e RDF che sono flessibili e molto dinamiche.

Uno strumento che si potrebbe desiderare di guardare è Stanford's Protege. È abbastanza potente e molto flessibile. È fondamentalmente un IDE e un framework web semantico. Quest'ultimo è scritto in Java, come lo è lo strumento. Tuttavia, lo schema web semantico ei file di dati creati da Protege e le modifiche potrebbero essere utilizzate da programmi scritti in qualsiasi lingua. Non c'è pregiudizio verso Java in questi file.

Inoltre, è possibile trovare molti schemi web semantici utilizzando Swoogle. Potrebbe esserci già uno schema che si adatta a qualsiasi applicazione.

Fondamentalmente, creare un file di schema in uno di questi molti linguaggi di convalida dello schema non è molto difficile una volta che si sa cosa si desidera inserire nel file di dati XML. Se non hai idea allora è improbabile che un programma o una persona sappiano cosa fare con esso quando lo leggono. In questo caso, XML potrebbe non essere la migliore rappresentazione di archiviazione. Non sono sicuro che qualcosa sarebbe.

Invece, si potrebbe semplicemente voler fare tutto ciò che si sta facendo in un linguaggio di script generico, tipizzato dinamicamente come Python o Ruby. È possibile utilizzare anche LISP, se si desidera che i propri programmi siano in grado non solo di avere formati di dati illimitati, ma anche di essere in grado di modificare se stessi.

Un'altra opzione per la memorizzazione dei dati senza schema è un linguaggio di programmazione logica. Questi di solito non hanno alcun schema. Hanno invece un ontology.

Due linguaggi di programmazione con cui ho lavorato molto utilizzando le ontologie sono CLIPS e Prolog. Sono disponibili implementazioni gratuite, open source, multipiattaforma.

Dai uno sguardo allo SWI-Prolog; veloce, semplice e potente. Puoi definire fatti al suo interno e regole che sintetizzano fondamentalmente i fatti a posteriori quando necessario. Estrai i dati con le query. Prolog è stato in realtà una fonte d'ispirazione per RDF quando è stato creato, già negli anni '90, come ricordo. La documentazione RDF originale utilizzata per fare frequenti riferimenti a Prolog. Se vuoi "scoprire" o "analizzare" o "trovare" cose sui fatti nella tua ontologia, Prolog è un ottimo linguaggio per scrivere tali applicazioni. È anche utile per l'analisi del linguaggio naturale.

CLIPS è anche bello, se stai cercando di risolvere i problemi sui fatti nella tua ontologia. È adatto per l'organizzazione, la risoluzione dei problemi e le applicazioni relative alla configurazione.

Se gli schemi non sono la vostra cosa, forse le ontologie lo sono. In caso contrario, forse dovresti semplicemente usare un linguaggio di scripting digitato in modo dinamico e conservare i dati memorizzati in oggetti complessi utilizzando mappe ed elenchi in file usando i loro meccanismi di persistenza standard.

Answer 4

Utilizzare MongoDB o altri database nosql. Vedi anche questo blog, Why I think Mongo is to Databases what Rails was to Framework.