Abbiamo tutti i tipi di ricerche nella nostra applicazione, memorizzate in una tabella separata, LOOKUP_T.
L'applicazione dovrebbe caricarli tutti all'avvio e mantenerli in una variabile del ciclo di vita globale oppure è opportuno continuare a eseguire piccoli spostamenti sul DB per recuperare queste ricerche a seconda dell'azione dell'utente? In molti casi questi viaggi saranno duplicati.
I viaggi DB per i recuperi di ricerca sono costosi nel mondo odierno?
È prassi consolidata non ottimizzare i programmi prima che tu non abbia
Detto questo, se hai l'indicazione che almeno uno dei valori di ricerca sta causando perdite di prestazioni, potrebbe essere semplice nel tuo caso fornire una soluzione generica che fornisce una strategia generale di precaricamento per tutti valori di ricerca (forse più semplici di una strategia individuale per un solo valore).
Se questa è la situazione, l'implementazione di tale pre-caricamento potrebbe andare bene. Essere consapevoli, questo non è gratis: precaricare hardcodes l'assunzione nel vostro programma che quei valore di ricerca non cambiano mai durante la vita del processo di applicazione, e se tale assunto diventa sbagliato, ciò comporterà ulteriori sforzi di sviluppo per mitigare questo.
Questo è noto come invalidazione della cache e spesso citato come uno dei due più difficili problemi in Informatica .
Are DB trips for lookup fetches expensive in today's world?
Questa tua domanda esprime un equivoco abbastanza comune: che si possa rispondere sensibilmente in generale. Per la mia esperienza l'unica risposta sensata è: dipende (sul DB, l'applicazione, l'intero sistema, la rete ecc.).
Ma permettetemi di rispondere a questa domanda in modo diverso: sì, è possibile che molti roundtrip DB possano diventare costosi in un sistema, specialmente quando la rete ha una latenza elevata (cosa non rara quando si accede a un DB su una rete geografica) , con molti router intermedi, canali VPN, crittografia dei dati, ecc.) Tuttavia, nulla tranne le tue misurazioni e le tue osservazioni possono dirti se questo è importante nel tuo sistema.
Il mio consiglio è di preparare la domanda per il preloading.
Tuttavia, non implementare il pre-caricamento effettivo, a meno che non si sia verificato un problema di prestazioni. Il precaricamento ha molti problemi, tra cui come notificare all'applicazione l'aggiornamento dei dati memorizzati nel database.
Quindi, non andare in giro a spargere query di database ovunque attorno al codebase nell'aspettativa che il preloading non sarà necessario. Invece, disponi di una posizione ben definita per il recupero dei valori con un'API compatibile con il precaricamento.
Con le moderne reti a bassa larghezza di banda a bassa latenza, SSD e grande RAM nel server di database, è probabile che il database non sia un collo di bottiglia al momento. Hai solo bisogno di essere preparato per il successo della tua applicazione. Cosa succede se i livelli di carico aumentano di 1000 volte?
È sicuramente una buona cosa che tu abbia considerato il pre-caricamento. Non implementarlo ancora, comunque. Prepara la tua base di codice per l'eventuale implementazione.
Leggi altre domande sui tag design web-applications website-performance