Progettazione architettonica di un'applicazione Web basata su database SQL e documenti

-2

Sto progettando un'applicazione web con Django come back-end. Panoramica del sistema è la seguente

  1. I dati vengono raccolti dall'utente collegato a entità diverse. Esempio: impianto, progetto, macchina, test, ecc.

  2. I blocchi di configurazione (file JSON con versione consolidata, completamente autonoma, datata e con versione) sono creati dall'utente selezionando diverse istanze delle entità precedenti in un pacchetto.

  3. Il blocco di configurazione viene inviato a un server API automatizzato, che genera al volo un API per detto blocco.

Sto provando a modellare la struttura del database nel passaggio 1.

Dettagli noti

  1. Diverse classi di entità. Ex. Impianto, Progetto, Macchina, ecc. Sono conosciuti in anticipo e sono corretti.

Tutto il resto è sconosciuto. Non conosco i dati nelle entità, i collegamenti tra loro, ecc.

Ho in programma Postgres dell'utente per i dati relazionali ricercabili e un database di documenti, CouchDB per gestire la parte dello schema di dati sconosciuti.

Architettura consigliata

Ho in programma di avere tabelle template per entità diverse, in un database Postgres, dove l'amministratore definisce un set di modelli per i dati che devono essere compilati dall'utente. Il modello è un documento JSON, con un protocollo per la definizione di diversi campi che l'utente compilerà.

La mia interfaccia utente leggerà il documento JSON e genererà al volo i componenti dell'interfaccia utente richiesti. Attualmente il piano è di creare un componente di reazione.

Ho diviso i dati dell'utente nelle seguenti categorie.

Validated Manual Input
Check Box
Selection from a list
Selection from a set of linked lists (Ex. State selection, then City selection, etc.)
Link to other documents (Ex. Location of a machine in a particular plant)

Ho in programma di avere un protocollo nel documento modello JSON che il processore UI comprenderà e arricchirà in modo appropriato l'interfaccia utente, eseguendo le chiamate API REST necessarie al back-end in base ai puntatori nel documento JSON.

Quindi, gli amministratori preimpostano un elenco di modelli. L'interfaccia utente converte i modelli in moduli di input dell'utente. Il sistema acquisisce i dati dai moduli e genera i dati rilevanti nel database Postgres e Document (CouchDB).

L'idea è di avere un set di documenti collegati nel database del documento, con lo schema definito dall'amministratore e un elenco di tabelle collegate staticamente nei postgres che incapsulano le relazioni note tra le entità.

L'architettura di cui sopra è un progetto abbastanza buono, come in, è un buon metodo per risolvere il problema della gestione dei dati senza conoscere lo schema prima della mano ??

    
posta Raghavendra Kumar 19.09.2017 - 06:08
fonte

1 risposta

0

Un'architettura dipende in modo critico dai requisiti non funzionali , ad es.

  • quanti documenti hai bisogno per essere in grado di elaborare sarà un input critico in quale archivio di documenti usare
  • o se il back-end deve supportare l'elaborazione basata sull'evento o no
  • i requisiti di gestione determineranno, se l'utilizzo e il mixaggio della tecnologia di archiviazione sono una buona idea
  • il costo e il prezzo determineranno, se è possibile costruire da zero.

Nella tua domanda hai solo dei requisiti funzionali.

Una buona architettura è semplice, supporta il raggiungimento degli obiettivi per i requisiti non funzionali e fornisce una netta separazione delle preoccupazioni. Dai un'occhiata agli stili di architettura , per esempi di modelli di architettura. Alcuni di questi potrebbero essere dati dalla tua scelta di Django.

Quali requisiti non funzionali ti portano a scegliere due livelli di persistenza? A mio avviso, ciò renderà più difficile il supporto e la progettazione.

    
risposta data 19.09.2017 - 07:04
fonte