Si tratta di una progettazione "overkill" per archiviare dati XML in un database relazionale? Un punto è che questi servizi REST API web possono essere successivamente utilizzati da altre applicazioni.
Spostamento di dati XML in DB [chiuso]
1 risposta
0
Dipende dalla complessità e dal volume dei tuoi dati e dall'importanza di questo "inserimento dati" o ETL (Estrai, Trasforma, Carica) servizio.
Per dataset di grandi dimensioni (100 KB o più di oggetti con codifica XML in entrata), che continueranno ad arrivare nel tempo e che sono una parte importante di un processo aziendale, si potrebbe obiettare che questo è "adatto al lavoro".
Per la maggior parte dei lavori "carica il database", tuttavia, è un enorme overkill. Ho eseguito più milioni di record ingerendo sistemi con operatori paralleli ma nessun servizio splitter, solo una semplice coda e nessuna segmentazione del tipo API. Il numero di diversi tipi di entità che hai descritto qui sembra andare contro Rasoio di Occam , che è spesso una guida saggia per quelli che costruiscono sistemi software.
Oltre alla probabile eccessiva complessità della pipeline, diverse preoccupazioni specifiche:
-
Vuoi davvero deserializzare da XML solo per ricalibrare in JSON? Presumibilmente non stai memorizzando quel JSON direttamente in un documento strutturato DBMS né verbatim in un campo di testo relazionale o blob. Dovrai farlo deserializzare nuovamente il JSON, creando due hop semantici. Adesso, JSON è un buon formato in generale per le API Web, ma anche XML è perfettamente cromulent per i lavoratori API Web da importare direttamente. Non è chiaro il perché ci dovrebbero essere così tante fasi preparatorie prima di quei lavoratori API. sembra probabilmente i preparativi aumentano notevolmente l'opportunità errori da introdurre.
-
L'idea di dividere i documenti XML in tipi di entità separati sembra rischiosa. I documenti che serializzano i dati spesso condividono un contesto comune (entità correlate, consistenza implicita della relazione, o entità che devono essere aggiunte al datastore atomicamente). scissione così presto nella tua pipeline e ricombinare in seguito è irto di opportunità per introdurre errori e disallineamenti semantici. Avresti bisogno fare molta attenzione a non farlo se i tuoi documenti hanno qualche relazione complessità di cui parlare. E dividendo i documenti serializzati così presto, staresti ignorando e rifiutando di usare le strutture che sono integrati in tutti gli ultimi DBMS relazionali per gestire tale coerenza requisiti. Mentre non è impossibile immaginare una situazione in cui ciò avverrebbe essere una scelta legittima, è molto più raro delle alternative più semplici.
Aggiornamento: ecco un diagramma di ciò che potrebbe comportare un processo semplificato:
