Utilizzo del campo XML Vs. creare una tabella per un'organizzazione instabile

Question

Utilizzo del campo XML Vs. creare una tabella per un'organizzazione instabile

#1 da (2 voti)
#2 da (1 voti)
#3 da (0 voti)
#4 da (0 voti)
#5 da (0 voti)

3

Sono in fase di progettazione un'applicazione per emettere e archiviare fatture per un'organizzazione. Il problema è che l'organizzazione non è affatto stabile. Esistono molti tipi di fatture che possono aumentare e cambiare.

Per prima cosa, ho provato a utilizzare le tabelle nel mio DAL, una tabella per archiviare le fatture, una per i campi fattura e una per i valori dei campi fattura. Il problema era che in questo modo è necessario Reflection per rilevare i campi in un secondo momento, e questo potrebbe rallentare l'applicazione quando la fattura contiene molti articoli.

In secondo luogo, ho cercato di mantenere il nucleo dei dati della fattura come due tabelle: fatture e articoli della fattura. Altri campi sono completamente estraibili da altri tavoli. Voglio dire, Business Layer dovrebbe fornire risultati diversi per tipo di fattura. Dovrebbe scegliere le domande giuste e elaborare i risultati in base al tipo di fattura. Due problemi con questa soluzione sono:

Ho ancora un sacco di join tra le altre tabelle quando voglio mostrarlo una fattura, per ogni articolo di fattura. Dovrei ricalcolare tutto ogni volta per ogni articolo di fattura.
Cosa succede se la tabella degli articoli della fattura non supporta un nuovo tipo di fattura? Quindi probabilmente dovrei aggiungere una nuova tabella per memorizzare quel tipo di articoli delle fatture.
Il mio cliente mi ha chiesto di conservare tutti i dati relativi a una fattura, lo fanno non voglio che lo ricalcoli ogni volta Vogliono qualcosa come un istantanea dei dati correlati al momento della creazione della fattura.

Ora, cosa penso posso utilizzare il vantaggio di XML nella tabella? Posso salvare la fattura, con qualsiasi campo come xml.

Posso salvare la versione diversa delle loro fatture.
In caso di modifiche, aggiorno solo Business.dll e non è richiesta alcuna modifica DAL.
Da Linq a XML non è lento.

Che cosa suggerisci?

object-oriented c# database-design entity-framework

posta Reza Owliaei 05.02.2012 - 09:44

fonte

5 risposte

Leggi altre domande sui tag object-oriented c# database-design entity-framework

scons e python unit testano le migliori pratiche Cosa si intende per "First Class Protocol"

score 2 · Answer 1

Nel complesso, questo è un buon piano. Ho implementato alcune cose che sono notevolmente simili ai miei tempi. Se stessimo iniziando a progettare qualcosa di simile oggi, prenderemo seriamente in considerazione l'utilizzo di un database di documenti piuttosto che di SQL, ma il dado potrebbe già essere lanciato.

Se stai usando SQL, ti consiglio di spingere tutti i dati al di fuori della fattura e nella tabella - è molto più facile interrogare e capire al volo. La roba all'interno di XML è un po 'più complicata da ottenere.

Una cosa che hai pubblicato merita un po 'di discussione:

On changes, I only update my Business.dll and no DAL change required.

Il formato dei dati o le modifiche dello schema all'interno della fattura sono probabilmente la cosa più difficile da gestire qui. Presumendo che tu stia usando XmlSerialization, le modifiche all'oggetto sottostante possono provocare il peggioramento degli arresti anomali nella migliore delle ipotesi o il danneggiamento dei dati nel peggiore dei casi. È davvero necessario creare un piano di controllo dello schema delle fatture dal giorno zero. Esattamente cosa fare dipende dai requisiti e con XML è piuttosto semplice modificare i dati sottostanti senza idratare gli oggetti, ma a un certo punto dovrai fare qualcosa se si prevede che questo sistema vivrà per un periodo di tempo significativo.

score 1 · Answer 2

suggerirei di applicare XML per architetture così altamente imprevedibili e non strutturate. Una soluzione basata sul web per il tuo problema può essere visto a link questa non sarebbe una soluzione plugin per il tuo problema. ma puoi vedere nel link precedente come questo problema può essere affrontato elegantemente. questo sicuramente ti aiuterà nell'architettura del tuo database.

score 0 · Answer 3

Suggerirei di utilizzare il superset di tutto il campo che può essere presente nelle fatture. Dire fattura1 ha campo A, B, C e fattura2 ha A, B, D quindi avere una tabella che ha la colonna A, B, C e D (supponendo che ci sono solo due tipi di fatture). E a seconda delle colonne per cui sono disponibili i dati, puoi creare la fattura1 o la fattura 2.

score 0 · Answer 4

Per prima cosa suggerirei di utilizzare tipi dinamici (come ExpendoObject) per rappresentare i dati non strutturati nel tuo livello aziendale. Ciò significherebbe meno classi personalizzate.

Secondo, vorrei raccomandare l'uso di json invece di xml dato che occuperebbe molto meno spazio nel database / motore di archiviazione.

In terzo luogo, hai preso in considerazione l'utilizzo di una soluzione di archiviazione nosql per le fatture? È molto più adatto ai dati meno strutturati rispetto al normale sql.

score 0 · Answer 5

Ho provato qualcosa di simile e sono stato scoperto!

Nel mio caso il sistema si è dimostrato un po 'troppo efficace e ora memorizza 2,5 milioni di transazioni ciascuna con un blob di dati Xml. La dimensione del database ora è di circa 25 GB e i backup iniziano a richiedere molto tempo.

Il problema principale è che Xml nei database non si comprime bene.

Sto pensando a una riprogettazione ora, in cui i documenti Xml sono archiviati nel file system. Sono di natura transazionale, ad es. scrivi una sola volta, leggi molti e non aggiorna mai.

I file Xml sul file system possono essere compressi o archiviati, se necessario.

Ci sono alcune considerazioni. I miei server usano NTFS, quindi anche il file più piccolo occupa 4kB di spazio su disco (la compressione aiuterà con quello). Anche la sicurezza e i backup devono essere considerati.