Come migliorare le prestazioni di serializzazione di grandi elenchi di oggetti composti

-1

Diciamo che abbiamo il classico oggetto Invoice .

Questo oggetto Invoice ha varie proprietà, tra cui un Product e Customer oggetto.

L'oggetto Product ha un minimo di 15 proprietà.

Ora dì che ho un elenco di fatture dei clienti che hanno acquistato tutti lo stesso prodotto. Quando serializzo questi dati sul client, la dimensione dei dati si avvicina a diversi megabyte (visibile nella scheda di rete di Chrome devtools). Questo non è un grosso problema per la mia macchina, ma su dispositivi mobili può portare a tempi di caricamento drasticamente più lenti.

Ogni Invoice in questo elenco contiene esattamente lo stesso Product , con le stesse proprietà 15+ che occupano spazio nella memoria. Sembra davvero inefficiente inviare questi dati ripetuti attraverso la rete. Mi servono solo le informazioni Product una volta, i dati importanti sono i clienti e le cifre di vendita, ecc., I dati che differenziano ciascuna fattura.

Come posso strutturare i miei dati in un modo che abbia una minima ripetizione dei dati?

EDIT: Per essere chiari, sto parlando delle dimensioni potenziali della risposta JSON e di come ridurla al fine di non far saltare in aria dispositivi mobili / dispositivi più lenti.

    
posta Eric Guan 04.05.2017 - 20:41
fonte

3 risposte

3

Pensa alla normalizzazione del database e alla denormalizzazione.

Le probabilità sono buone nel tuo database, hai tabelle separate per Fatture, clienti, prodotti, ecc. e altre tabelle che mappano gli elementi di quelli tutti insieme (o qualche disegno simile). Quando hai la tabella delle fatture, invece di mettere tutte le informazioni del cliente in una riga, spesso ti basta avere una chiave esterna, con un singolo intero o simile che corrisponda a un identificativo sulla riga del cliente nella tabella dei clienti. Quando produci la tua lista, tu JOIN tutte queste informazioni insieme e le fai rapporto.

Quando serializzi quell'elenco, la chiave esterna alla mappatura degli ID viene persa e il contenuto di ogni pezzo di JOIN ed informazioni viene ripetuto più e più volte, che è il problema che stai riscontrando.

Quindi, una soluzione è portare un po 'di quella che unisce l'intelligence al cliente. Invia le tue fatture e prodotti come liste separate e usa il tuo software sul lato client per mettere insieme tutti i pezzi, facendo riferimento a chiavi e ID, proprio come farebbe il database.

    
risposta data 04.05.2017 - 21:23
fonte
1

Man mano che le fatture vengono compilate, fai riferimento all'ID del prodotto come parte della fattura, non all'intero prodotto.

invoice
product id=1...
product id=1...

Poi hai un'altra sezione che è la tua lista di prodotti che elenca ogni prodotto una volta .

  • id prodotto = 1, nome = Widget, 15 successive proprietà ecc ....
  • id prodotto = 2, nome = Fidget, 15 successive proprietà ecc ....

Quindi il tuo cliente può utilizzare gli ID di riferimento per trovare il prodotto completo per ciascun elemento pubblicitario della fattura.

    
risposta data 04.05.2017 - 21:18
fonte
0

Non hai spiegato perché questo è un problema. Normalmente, se un oggetto del tipo di prodotto è riutilizzabile, dovrebbe essere riutilizzato e il framework di serializzazione (se presente) riconoscerà che è lo stesso oggetto ed evita di ri-serializzare l'oggetto.

Sai già come strutturare i dati: riusare Prodotti identici. Fare uso di una migliore struttura di serializzazione è una questione separata. In genere un efficiente framework di serializzazione non tenta di salvare tutto come un grafo aciclico diretto, ma piuttosto come un elenco di oggetti piatto, con identificatori di oggetti sintetizzati (tipicamente interi) usati per connettere gli oggetti insieme. Tale framework non ha bisogno di serializzare in modo ridondante lo stesso oggetto.

    
risposta data 04.05.2017 - 20:54
fonte

Leggi altre domande sui tag