SQL Registrazione vs query separata in codice senza Join - Prestazioni

Question

Vorrei sapere se c'è un guadagno in realtà di prestazioni tra queste due opzioni:

Opzione 1:

• faccio una query SQL con un unisciti per selezionare tutti gli utenti e i loro ranghi.

Opzione 2:

• faccio una query SQL per selezionare tutti gli utenti
• prelevo tutti gli utenti e fare un altro query SQL per ottenere le fila di questo utente.

Nel codice, l'opzione due è più facile da realizzare per me. Questo è solo il modo in cui disegno il mio livello di Persistenza.

Quindi, vorrei sapere qual è l'impatto sulle prestazioni. Dopo quale limite dovrei prendere in considerazione l'opzione 1 anziché l'opzione 2?

Answer 1

In generale, il server DB è sempre più veloce all'entrata del codice dell'applicazione. Ricorda che dovrai eseguire una query aggiuntiva con un round trip di rete per ogni join. Tuttavia, se il tuo primo set di risultati è piccolo e gli indici sono ben sintonizzati, questo modello può funzionare correttamente.

Se stai facendo solo questo per riutilizzare la tua soluzione ORM, allora potresti combattere una battaglia persa. Ho sempre trovato che ho bisogno di set di dati di sola lettura che possono essere prodotti solo con SQL, quindi ora uso ORM per le operazioni CRUD per oggetto e SQL regolare per ricerche, report, aggregati, ecc.

Answer 2

Dipende dal numero di utenti che anticipi. L'opzione uno sarà sicuramente più veloce, ma con una quantità ragionevole di dati, la differenza sarà trascurabile.

Answer 3

Se i ranghi sono valori statici, prendere in considerazione la memorizzazione nella cache dell'applicazione.

Se si ha bisogno di utenti frequentemente e ranghi solo raramente, si consideri il caricamento pigro dei ranghi. (ad esempio, query separate, ma la seconda query viene utilizzata solo occasionalmente).

Utilizzare il join se sono sempre necessari entrambi i set di dati e devono essere copie correnti del database.

Prototipare qualsiasi scelta probabile ed eseguire test delle prestazioni.

EDIT: Ulteriori riflessioni sul livello di persistenza, perché sto di fronte a questo uno io. Prendi in considerazione l'aggiunta di classi di tipo "persistente" che gestiscono i join come query di base e sono di sola lettura. Se questo si adatta al tuo particolare scenario, devi decidere, ma un sacco di accesso al database per molte app si basa sui join, che possono essere piuttosto grandi e complessi. Se riesci a gestirli in modo coerente con i tuoi oggetti persistenti e aggiornabili, può essere un grande vantaggio per l'architettura generale. Concettualmente, è come avere una vista nel database e interrogare la vista invece di scrivere un join, ma lo stai facendo tutto in codice.

Answer 4

In 99% situazioni si uniscono sarà più veloce.

Tuttavia, vi è una rara situazione in cui può essere più lento. Se stai facendo uno o più join sulla tabella con grandi dimensioni di riga e stai raggiungendo il limite della larghezza di banda della rete.

Ad esempio, c'è una colonna BLOB in T1 di 1 MB, si sta entrando in T2 che consiste di 100 righe per ogni riga T1. Il set di risultati sarebbe il conteggio di righe T1 multiplo 100.

Quindi, se si sta interrogando una riga T1 con join, si otterrà 100MB di risultati, se si recupera la riga T1 (1MB) e quindi si seleziona separata per recuperare 100 T2 per questo T1 il set di risultati sarà 1MB.