Come mitigare i problemi relativi ai feed di dati di terze parti?

La data di memorizzazione nella cache ha senso in determinate condizioni:

• Lavorare su una vecchia serie di dati ha ancora senso. Immagina le banche che eseguono operazioni di compravendita su vecchi dati di mercato!
• Rendi l'utente consapevole del fatto che sta lavorando con dati meno recenti. Aggiungerei un indicatore all'applicazione che fornisce un suggerimento "Stai attualmente lavorando su un set di dati più vecchio."

Dovrai decidere se vuoi memorizzare nella cache i dati sull'applicazione del livello di rete.

Livello applicazione

A livello di applicazione significa meno lavoro per te, ma funziona solo in modo affidabile se il feed si aggiorna spesso e c'è una buona probabilità che tu possa prendere un feed valido entro un paio di minuti).

Il solito schema di accesso ai dati è probabilmente simile a:

Download -> Parse -> Validate -> Use in business logic

Questi passaggi dovrebbero essere incapsulati in classi diverse, invisibili alla logica aziendale. È semplice chiedere a una classe di "fornire dati per favore" . Puoi usarlo a tuo vantaggio aggiungendo un "caching" Vorrei aggiungere il seguente passaggio:

Download -> Parse -> Validate -> Store -> Use in business logic

Con store voglio dire salvare qualsiasi dato che possiedi dopo la validazione (che può essere una stringa grezza o alcune classi deserializzate) ad un qualche tipo di archiviazione di dati astratti (diverse implementazioni possibili, db, file , memoria). Si tratta fondamentalmente di un'applicazione del schema di decorazione .

Livello di rete

È inoltre possibile creare un semplice server Web che funge da proxy. Ad ogni richiesta il server tenta di ottenere una versione dall'origine remota ed esegue l'analisi e la convalida dei suoi contenuti. Se ciò è valido, sostituisce il contenuto della sua cache corrente e restituisce la cache alla tua applicazione.

Per ridurre la quantità di modifiche all'applicazione, il server proxy si comporterebbe allo stesso modo del server remoto. Tuttavia, potresti voler aggiungere un attributo al feed restituito indicando che è memorizzato nella cache (per visualizzarlo nella tua applicazione). Non dovrebbe impiegare troppo tempo uno sviluppatore esperto per farlo.

Sono stato in questa posizione, in cui avevamo dati errati in un feed esterno e temevamo continuamente che il feed interrompesse il nostro sistema ogni giorno.

Il mio consiglio:

• Prova a correggere i dati nel feed, se possibile. Ad esempio, abbiamo notato che sebbene il feed fosse XML, non era un XML valido. Abbiamo finito per implementare uno script che lo risolva come XML valido.
• Convalida i dati. Difficile! In effetti, fai ogni singolo controllo di validazione che riesci a trovare. Puoi disattivare qualsiasi controllo temporaneamente o permanentemente se il controllo particolare è troppo severo.
• Implementa controlli di integrità e molti "vuoi andare avanti?" domande. Ad esempio, se nel database sono presenti molti oggetti, un feed errato potrebbe finire per eliminarli tutti. Quindi, molto probabilmente vorrai una domanda "cancellando 100.000 oggetti, vuoi andare avanti?". Un modo per farlo è avere un'opzione "a secco" per gli script di gestione dei feed che stampano statistiche sul numero di oggetti modificati, ma in realtà non fanno nulla.
• Se alcuni oggetti del database sono particolarmente importanti, "proteggeteli" in modo che le informazioni sulle loro modifiche vengano comunicate alla persona che esegue gli script del feed e la persona possa quindi esaminare le modifiche manualmente e vedere se hanno senso.
• Scarica il feed tutte le volte che puoi! Se il feed viene aggiornato ogni settimana, non si vuole perdere nessuna settimana. Scaricalo ogni settimana! In effetti, imposta gli script per farlo perché altrimenti lo dimenticherai un giorno.
• Utilizza la versione più recente del feed che sembra soddisfare i tuoi standard di qualità.
• Se il feed si interrompe, informa le persone che gestiscono il feed il prima possibile e chiedi loro di risolverlo rapidamente. Se tratti il feed come una scatola nera che non usa il feedback, otterrai un feed che sarà spesso rotto. Le persone che gestiscono il feed devono essere informate di tutti i problemi nel feed.
• Conserva le copie storiche compresse del feed. Se lo spazio su disco diventa un problema, verifica se la compressione delta potrebbe salvare la tua giornata.

Con questo consiglio, sono sicuro che puoi avere sia dati aggiornati nel tuo database che anche mitigare i problemi che potrebbero finire per causare gravi danni al tuo database.