Come dovrei confrontare due tabelle di database, con SQL o Java? [chiuso]

A meno che tu non abbia qualcosa che l'applicazione deve fornire continuamente, penso che sarebbe meglio lasciare che il materiale relativo al database sia gestito dal database stesso.

Ciò ti consentirà di fare in modo che il DB faccia tutto il lavoro pesante, consentendo al contempo all'applicazione di rimanere il più leggera possibile in modo che possa gestire tutto ciò che l'utente ha bisogno di fare.

MODIFICA: come da commento.

Dalla mia esperienza, lasciando tutti i calcoli sull'applicazione, crea più problemi che risolve. A meno che i calcoli che stai facendo appartengono esclusivamente a come i dati interagiranno con l'utente, il che significa che l'applicazione deve gestire tutte le operazioni che riguardano il modo in cui i dati saranno presentati all'utente.

Eseguendo qualsiasi operazione che implichi strettamente i dati, come ad esempio ottenere tutti gli utenti con un determinato campo o come nel tuo caso, la sincronizzazione dovrebbe essere lasciata a livello di DB. Questo ti permetterà di:

• Lasciare la maggior parte del sollevamento pesante a livello di DB. I DB sono generalmente bravi in quello che fanno, quindi se gli permetti di fare le loro cose, la tua applicazione sarà più leggera (e molto probabilmente più reattiva). Questo dovrebbe a sua volta rendere felici gli utenti perché l'applicazione non è clunky.

• Salva risorse: quando si estraggono dati dal DB, si apre una connessione e la si mantiene aperta fino al termine del trasferimento dei dati. Le connessioni sono risorse costose che dovrebbero essere utilizzate solo quando necessario. Tirare tutte le informazioni nel DB in modo da poter operare su di esso, e quindi inviarlo indietro significa che la connessione verrà hogged per un po 'di tempo. Se hai molte applicazioni che usano il DB, questo potrebbe significare che l'applicazione molto probabilmente non scalerà molto bene.

• Quanto sopra può portare a problemi di larghezza di banda se l'applicazione e il DB sono in esecuzione su macchine diverse. Ciò può rendere più costosa la manutenzione dell'applicazione.

• Avere una stored procedure che fa la logica ti offrirà una maggiore flessibilità per applicare le modifiche. Se si dispone della logica a livello di database, è sufficiente apportare la modifica in un'unica posizione per ottenere le modifiche necessarie senza dover pubblicare una nuova applicazione. Ciò significherebbe quindi che puoi essere certo che tutti gli utenti eseguono la stessa logica, anziché avere utenti che eseguono la versione n dell'applicazione, mentre altri che eseguono la versione n + 1 .

what way is correct ...

Essere cinici solo per un momento, nessuno di loro.

Prova come potremmo; non abbiamo mai ricevuto completamente . Ma possiamo provare.

... for performance ...

Database.

Per la potenza di elaborazione dei dati grezzi, sfrutta il tuo DBMS. Non si dice quale si sta utilizzando, ma tutti i Big Players hanno una sorta di linguaggio procedurale (PL / SQL, T-SQL, ecc.) In cui è possibile scrivere codice, utilizzando tutta la potenza del database e senza quelle brutte spese generali di rete.

... and future support?

E c'è il problema.

Potresti scrivere qualcosa che viene eseguito all'interno del database ed è incredibilmente veloce, ma se nessun altro in azienda conosce questa lingua, allora hai un problema. Potrebbe essere meglio sacrificare quella potenza cruda per un programma scritto in qualcosa di più "mainstream"; tranne in pochissimi casi, la manutenibilità dovrebbe essere la priorità numero 1, anche a scapito della velocità in linea retta.