usando il divano db e il server sql fianco a fianco

Question

Al momento disponiamo di un database SQL relazionale sql server che è il nostro database di applicazioni master. Stiamo cercando di migliorare un meccanismo di archiviazione dei documenti esistente che utilizzi tipi di dati xml con qualcosa di più schematico che possa gestire documenti simili ma non identici e pensiamo che couchdb sarebbe adatto.

L'idea è che i metadati comuni relativi ai documenti possano essere memorizzati all'interno di SQL Server per facilità di visualizzazione/aggregazione/reporting, ma i documenti effettivi vengono memorizzati nel divano per gestire le sottili differenze nei documenti. L'idea è di sfruttare al massimo le due diverse tecnologie.

Ad esempio lo stato, il tipo, la persona correlata e la data di creazione sarebbero tutti comuni su tutti i documenti e memorizzati in sql ma una e-mail e una lettera (ovviamente con campi diversi) potrebbero essere memorizzati nel divano.

Quindi possiamo visualizzare la griglia del documento per tutti i tipi di documento (migliaia di documenti) che possono essere interrogati tramite sql ma la visualizzazione del documento ottiene i dati dal divano quando l'utente richiede di visualizzarlo.

Qualcosa da tenere a mente è che alcuni tipi di documento sono generati da modelli che sono anche documenti stessi (si pensi alla stampa unione/trova e sostituisci).

livello di applicazione è asp.net 4.5, C#, Pattern Repository, Windsor per CIO, JavaScript

Così, alla domanda ...

È questo approccio un modo ragionevole per rendere la maggior parte del due diversi paradigmi di archiviazione dei dati?

Stiamo rendendo inutilmente complessa la nostra vita di programmazione nel desiderio di "utilizzare la tecnologia più appropriata per il problema"?

Qualcuno ha qualche esperienza di provare qualcosa di simile e se sì, come è andata?

Answer 1

Non è raro utilizzare due diversi formati di archiviazione per un documento: uno per gli aspetti ricercabili ei metadati e un altro per la presentazione.

Guardando in modo più generale, l'approccio è in qualche modo simile a quella che abbiamo sviluppato al Royal Danish Library e spinto nel progetto Planets UE:

http://www.researchgate.net/publication/221176211_Archive_Design_Based_on_Planets_Inspired_Logical_Object_Model

Ecco un altro giornale che discute questo approccio in un modo più generale: "Opening Schrödingers Library"

L'obiettivo era archiviare. Abbiamo riconosciuto che durante la conversione di documenti per l'archiviazione o la conservazione, nessun formato di archiviazione del sigle era superiore in tutti gli aspetti della conservazione di attributi, formati, aspetto, contenuto ecc del documento originale. Soluzione: converti in diversi formati e utilizza un oggetto digitale sofisticato per tracciare le conversioni e quali aspetti dell'originale sono stati meglio conservati in quale conversione.

Quindi, a mio parere, l'approccio è teoricamente e praticamente valido.

Problemi pratici: probabilmente avrai bisogno di una sorta di oggetto digitale che tenga traccia delle varie parti di un documento, ad es. se si verifica in un solo sistema (e quindi quale), o in entrambi. Sembra che tu stia per utilizzare SQLserver per questo aspetto e ciò sembra ragionevole.

Realmente abbiamo implementato il modello di oggetto che descriviamo sul foglio e, infine, ho sentito che lo stanno ancora utilizzando.