Pricing File Creator

Naviga le tue risposte
3

problema Abbiamo un certo numero di clienti diversi che ottengono un numero di file di prezzi diversi, ogni cliente può quindi avere anche diversi stili di file di prezzo, ad esempio i clienti possono avere solo due colonne, prodotto e prezzo. Alcuni clienti possono avere fino a 20-30 campi ognuno di questi campi può esistere in diverse tabelle nel database. Anche il numero di prodotti all'interno del file può variare anche alcuni con solo un paio di centinaia di altri con oltre 10k. Questi file devono quindi essere eseguiti ogni ora per mantenere aggiornati lo stock e i prezzi. In media ci sono circa 50 diversi formati di file per 180 file di prezzo, quindi in totale i 9000 file dispari da scrivere.

Soluzione corrente La mia soluzione corrente per questo è due tabelle. Una tabella con tutti i prodotti all'interno di ciascuno dei file di prezzo insieme con i prezzi in varie valute. E un'altra tabella / vista con tutti i possibili attributi del prodotto. La chiave primaria è il codice prodotto, quindi altri campi, ad esempio una breve descrizione, una descrizione lunga, codici prodotto alternativi ecc.

Il programma carica quindi entrambe le tabelle in memoria: 

ConcurrentDictionary<PRODUCT_CODE, ConcurrentDictionary<COLUMN_NAME, VALUE>>

Ho quindi la tabella delle definizioni dei prezzi. La tabella quindi specifica il formato del file di prezzo per eample, il file di prezzo x ha colonna ' Product_Code', 'Price_GBP', 'Description' il programma, quindi itera (parallelo) attraverso i prodotti all'interno del file di prezzo corrente e cattura le colonne dal dizionario concorrente in memoria. Oltre alle colonne nel dizionario, ci sono tutte le colonne "Programmabili", ad esempio 'RRP - price_gbp *1.4' . Basta semplicemente passare a un caso di scambio per vedere cosa deve fare con queste colonne.

Problema Il mio problema è che il numero di attributi del prodotto sta diventando molto grande e il numero di file di prezzo e formati di prezzo e i clienti che desiderano questi file è quasi 10 volte piegato negli ultimi due anni scrivo questo sistema Quindi, come puoi immaginare, il suo tempo di esecuzione non è così rapido come prima.

Non riesco comunque a pensare di renderlo più veloce, ordinato e "a prova di futuro".

    
posta Houlahan 17.02.2017 - 11:25
fonte

2 risposte

0

Il caricamento di tutte queste tabelle in memoria sembra molto costoso, almeno se la struttura dei dati in memoria non è ottimizzata.

Potresti invece creare una query oggetto per ogni file da generare, in base a price_file_definition_table . L'oggetto query SELEZIONA le colonne pertinenti nelle tabelle pertinenti e le unirà con la tabella product_for_customer riservata al cliente specificato. Ciò consentirebbe al tuo RDBMS di organizzare e ottimizzare l'accesso ai dati. Dovresti semplicemente ripetere il set di risultati per produrre ogni file.

Questo produrrà prestazioni di gran lunga migliori rispetto a interpretare te stesso le formule ed eseguire la trasformazione richiesta, o la ricerca della colonna di destra per ogni linea.

Potrebbero essere utilizzate anche altre possibilità, come l'uso di una strategia per i prezzi, ma non mi è chiaro se il formato del file di prezzo è correlato a un insieme di prodotti o a un cliente, né se diversi clienti condividono lo stesso formato, né se i formati si evolvono frequentemente.

    
risposta data 18.02.2017 - 14:56
fonte
0

Crea una visualizzazione per ogni formato
So che sembra un po 'di lavoro ma potrebbe essere eseguito rapidamente

Sul tuo dizionario non è chiaro che ti occorrono concorrenti. Presumo che tu lo carichi prima. Non hai bisogno di concurrent per le letture parallele. Concorrente è più lento.

    
risposta data 18.02.2017 - 16:47
fonte

Leggi altre domande sui tag

Come determinare la frequenza di rilascio ottimale per il massimo rendimento? Permettere agli utenti di aggiungere i propri campi personalizzati in un'applicazione Spring MVC Hibernate - Qual è l'approccio ideale?