RDBMS SQL: una query o più chiamate

Per prima cosa devi mettere la correttezza. Crea le tue strutture dati in modo che modellano il dominio in questione in un modo corretto ed efficace che faciliti il funzionamento del tuo codice.

Oltre a ciò, cerca di minimizzare le chiamate al database, specialmente se il database non è locale (risiede sulla stessa macchina del programma che lo chiama). La latenza della rete è una considerazione reale qui e può essere non banale.

Supponiamo che tu abbia un'operazione che richiede 10 chiamate al database. Se la latenza della rete è di 100 ms, questa operazione impiegherà 1 secondo di overhead puro comunicando con il server, oltre a quanto tempo ci vorrà per eseguire effettivamente il lavoro. Se la latenza è 1 secondo, sprecherà 10 secondi solo sulla latenza di rete. Ma se riesci a scendere da 10 chiamate a 1, all'improvviso anche in condizioni di latenza davvero brutte, non stai perdendo molto tempo a causa del sovraccarico della rete.

Come regola generale, se stai semplicemente recuperando i dati semplicemente (e non facendo un'elaborazione pesante dei dati all'interno del server del database o sul client), il più grande collo di bottiglia di gran lunga in un sistema con un database non locale sarà la latenza di rete. Quindi, se riesci a ridurre il numero di chiamate, anche se ciò significa che devi eseguire un lavoro extra sul lato client una volta recuperato, probabilmente continuerai a farlo.

Come sempre, ricorda la regola più importante dell'ottimizzazione: misura per prima! ottimizza con i dati rigidi, non con le regole empiriche come quella che ho appena descritto, o potresti facilmente finire a fare molto di duro lavoro che rallenta le cose! Ma in generale, mantenere il numero di query verso il basso è solitamente il miglior percorso.

Suggerisco di prendere in considerazione l'utilizzo di DTO dopo aver eseguito il join corretto sull'origine dati utilizzando SQL (se si utilizzano RDBM). Inoltre, è anche possibile utilizzare il concetto Set di risultati multipli per restituire diversi gruppi di oggetti in 1 chiamata al server, se necessario.

DTO non è POJO (vedi: Differenza tra DTO-and-POCO - So che non stai chiedendo di .NET ma il concetto è probabilmente simile per questo argomento.)

Utilizzando questo approccio comunicherai meno dati tra il server e il client e non dovrai eseguire manualmente i join nella logica del client, che a mia conoscenza, Java non fornisce un equivalente di LINQ di .Net.

Inoltre, considera l'utilizzo (o la conoscenza) di un buon ORM. Molto probabilmente un buon ORM ti offrirà un approccio pratico.

Se la query restituisce più righe del previsto, la query viene scritta in modo errato.

Devi eseguire una query per ottenere i dati per Customer POJO. Quella query dovrebbe restituire una singola riga, quindi il DAO popola un singolo POJO.

Quindi viene eseguita una seconda query per ottenere le righe dalla tabella "many", data la chiave esterna (ID cliente) e creare tanti POJOS quante sono le righe trovate. Quindi quella lista di oggetti indirizzo è assegnata al POJO del cliente.

Customer class ha un membro di tipo List<Address>.

Se l'accesso al DB è costoso, puoi farlo pigramente, vale a dire, recuperare gli indirizzi solo quando viene chiamato per la prima volta getAddress di getAddressList .

La stessa tecnica può essere utilizzata per tutte le aggregazioni o composizioni nella classe Customer che vengono lette dal DB.

EDIT:

Informazioni sulle prestazioni: la tabella clienti deve avere un PK, forse ID cliente, quindi il recupero della riga deve essere velocissimo se si utilizza un RDBMS moderno. Anche le tabelle figlio devono avere un PK e un FK che punta al PK della tabella padre. Quella FK è anche indicizzata. È come l'attività di base per cui è stato creato un RDBMS.

Per quanto riguarda il traffico di rete tra l'app server (o l'app client) e il server DB coinvolto, anche questo può essere ottimizzato.

Il punto è:

Le problematiche relative all'hardware e ai trasporti possono essere risolte pubblicando denaro in quel momento.

Problemi di complessità derivati dalla scrittura di codice per fare cose che RDBMS fa in modo più efficiente, non può essere risolto lanciando loro denaro .

L'hardware costa poco, i programmatori sono costosi.