Quale strategia dovrei impiegare usando C # per risolvere questo caso d'uso?

5

Quindi questo è tutto ipotetico e teorico in realtà. Questo non è un vero sistema che dovrei architetto, ma è una buona domanda.

Una società memorizza e riproduce contratti. I contratti possono avere molti documenti associati con loro. Ci sono fino a 200 tipi di questi documenti che possono essere assegnati a qualsiasi singolo contratto.

Questo è fondamentalmente in poche parole. Non voglio scrivere 200 classi e disporre di 200 tabelle server SQL in riferimento a ciascun tipo di documento. Esiste una soluzione più efficiente per raccogliere i contratti / documenti in un database e quindi classificarli in un'app Web C # da visualizzare?

    
posta tshoemake 22.12.2016 - 23:57
fonte

2 risposte

4

Come Niklas H ha scritto in un commento mentre scrivevo questo:

Hai una tabella per i contratti.

Quindi hai una tabella per i documenti che include una chiave esterna per le tabelle dei contratti per il contratto a cui appartiene il documento.

Hai quindi una tabella dei tipi di documenti in cui sono presenti i tuoi tipi di documento. Dalla tabella del documento hai una chiave esterna per la tabella del tipo di documento, in modo che tu possa memorizzare il tipo di documento.

Questo ti permetterà di creare nuovi tipi di documenti senza dover creare nuove classi. Questi tipi di documento non saranno enumerati.

Avrai bisogno di una finestra di dialogo nel tuo sistema in cui puoi creare nuovi tipi di documenti, probabilmente avranno un nome e una descrizione.

Quando si inserisce un nuovo documento, si seleziona il tipo di documento dall'elenco dei tipi di documento esistenti.

    
risposta data 23.12.2016 - 00:04
fonte
1

Si potrebbe semplicemente archiviare il documento stesso nel database e non preoccuparsi di altre tabelle attorno ai tipi ecc. I sistemi di documenti più popolari hanno proprietà e metadati associati ad esso, quindi usalo invece di un sistema predefinito di tabelle.

La tua domanda è abbastanza ampia, ma supponiamo che tutti i documenti siano archiviati nel database come PDF. Anche se non fossero il processo avrebbe funzionato allo stesso modo. Uno potrebbe avere una serie di proprietà / metadati standard per il documento e quindi leggere i dati dal documento stesso (PDF) invece delle tabelle.

Se fosse necessario eseguire una ricerca o una query, estrarre tali informazioni e inserirle in una tabella in modo che si possano scrivere query su di essa sarebbe utile come menzionato da @Bent e altri.

Potresti anche fare un passo avanti e mentre il documento viene caricato nel database il tuo processo esamina i metadati del documento, memorizza parti importanti di quei dati in una tabella per riferimenti futuri e salva il documento e i dati. Non è necessario alcun tipo di tabella di riferimento perché mentre gli utenti caricano i documenti vengono utilizzati i metadati per il documento per classificare e contrassegnare il documento. In questo modo vengono aggiunti automaticamente nuovi tipi senza la necessità di mantenere alcun dato di riferimento.

Quindi, una tabella per contratto. Una tabella per i documenti. Un contratto / documento da molti a molti se i documenti possono essere condivisi tra i contratti. se non solo vai con l'FK come menzionato da @Bent.

La tabella dei documenti potrebbe avere anche le proprietà importanti o potrebbero essere separate in tabelle di riferimento separate.

    
risposta data 23.12.2016 - 17:01
fonte

Leggi altre domande sui tag