Memorizzazione di informazioni grafiche disegnate nel database per l'applicazione web

Question

Memorizzazione di informazioni grafiche disegnate nel database per l'applicazione web

#1 da (1 voti)
#2 da (1 voti)
#3 da (1 voti)

1

Durante lo sviluppo di un'applicazione Web che consente agli utenti di disegnare grafici (diagrammi di flusso, diagramma ER, UML, .... ecc.), le informazioni sugli oggetti disegnati e sulla loro relazione e posizione su tela sono espresse come oggetti JSON

La domanda è:

1- sta salvando tale grafico nel database come grezzo (testo dell'oggetto json) è sufficiente (in un campo di una tabella) 2- o è sempre necessario abbattere l'oggetto JSON in parti logiche e memorizzarle in una struttura di database ben costruita!

L'opzione 1-, oltre a rendere la vita dei devilopers più facile, eliminerà la necessità di ricreare oggetti json da piccoli pezzi e informazioni quando l'utente apre un grafico che ha costruito e salvato molto tempo fa

L'opzione

2- avrà dettagli a grana fine nella struttura corretta, ma avrà un costo di elaborazione pesante mentre si apre un grafico salvato dal database

quale via è corretta?

web-development web-applications database-design graph

posta Ali 04.09.2013 - 11:16

fonte

3 risposte

Leggi altre domande sui tag web-development web-applications database-design graph

Combina dati da due tabelle: è necessaria una guida Quanto tempo occorre dedicare ai casi d'uso?

score 1 · Answer 1

Alcune considerazioni su un oggetto gigante sono:

1-Tempo per fare query specifiche (ad esempio, le proprietà dell'elenco dell'oggetto Cliente non dovrebbero richiedere il caricamento di un modello con 200 oggetti)

2-Tempo per salvare le modifiche in un piccolo numero di elementi (ad esempio quando si modifica il nome dell'oggetto Cliente, è sufficiente salvarlo e non l'intero modello)

3-Se più di 1 utente interagirà con il tuo sistema, non puoi utilizzare 1 oggetto enorme senza il controllo della concorrenza appropriato, altrimenti alcuni utenti potrebbero andare persi a causa delle sovrascritture.

Ora se vuoi salvare il modello dell'utente in oggetti separati, devi avere una buona progettazione del database per il tuo meta modello. Tale meta modello non è banale da progettare.

score 1 · Answer 2

is it always required to break down the json object into logical pieces and store them into a well built database structure

Bene, non so chi ti dice cosa è richiesto e cosa no, ma nei casi d'uso più comuni che conosco non avrà senso. Un diagramma di flusso, un diagramma ER ecc. È una sorta di documento grafico in cui raramente ha senso

modifica il documento contemporaneamente a più di un utente (ho visto alcune prove in passato, ma mai una che ha funzionato bene)
query per cose come "get me tutti i grafici con una linea che inizia al punto x1, x2".

Tuttavia, ciò che ha senso è memorizzare alcuni meta-dati nei campi tabella standard associati alla stringa JSON. Ad esempio, titolo del diagramma, autore, ora di creazione, tipo di diagramma, tag di categoria, una breve descrizione, informazioni geografiche, un numero di versione e così via. Pensa a quale tipo di query di ricerca davvero ti aspetti, quel tipo di dati che dovresti modellare esplicitamente.

score 1 · Answer 3

Dividere il disegno di un utente in nodi e spigoli (e tutti gli attributi associati) e archiviarli in tabelle ti darebbe il vantaggio di poter interrogare un disegno.

La domanda è: hai davvero bisogno di quella funzionalità? Oppure potresti scappare semplicemente memorizzando alcuni metadati con la rappresentazione testuale del grafico?

Considera che ci sarà molto più lavoro da fare per ottenere un disegno dal database se ha molti nodi, rispetto all'estrazione di un campo di testo di grandi dimensioni.