Pro e contro di ordinare i dati nel DB?

Question

Supponiamo ho una tabella con il campo di tipo VARCHAR. E ho bisogno di ottenere i dati da quella tabella ordinati alfabeticamente da quel campo.

Qual è il modo migliore (per prestazioni): aggiungere order by field alla query SQL o ordinare i dati quando sono già stati recuperati?

sto usando Java (con Hibernate), ma non posso dire nulla su motore DB. Potrebbe essere qualsiasi database relazionale popolare (come MySQL o MS Sql Server o Oracle o HSQL DB o qualsiasi altro).

La quantità di record nella tabella può variare notevolmente, ma supponiamo ci sono 5k record.

UPD: quanto bene fa 2 ° livello hibernate cache (EHCache per esempio) il supporto di dati allineati?

Answer 1

Se questo campo è indicizzato, il DB medio sarebbe molto più efficiente in questa attività rispetto a Java. Si noti inoltre che normalmente non recuperare tutti quei file in una sola volta se è per la visualizzazione puro, ma piuttosto recuperare un sottoinsieme di esso in modo che possa essere dimostrato impaginazione. Puoi farlo anche a livello di database. Ordinare i dati in Java richiederebbe l'intera tabella trascinata nella memoria di Java, non si desidera farlo.

---

In Hibernate è possibile ordinare i risultati utilizzando Criteria#addOrder() e impaginare con Criteria#setFirstResult() e Criteria#setMaxResults(). Per esempio.

Answer 2

Ordina i dati nel database - che è (parte di) quello che è lì per. Il motore di database è probabilmente migliore per ordinare questi dati rispetto a te.

Answer 3

La mia soluzione sarebbe creare indice per la colonna di ordinamento e scrivere query con ordine per clausola.

Answer 4

Qual è il modo migliore (per prestazioni): aggiungere ordinamento per campo alla query SQL o ordinare i dati quando sono già stati recuperati?

E 'ORDER BY, non ordina per.

È una questione di compromesso: l'ordinamento sul lato client è distribuito, il che significa meno impatto sul server. Tuttavia, può richiedere più risorse client.

Se il campo non è indicizzato, per restituire l'intero ordinato, recordset server sarà necessario fare le seguenti cose:

1. recuperare l'intero set di record
2. Ordina che
3. Invia sopra il rete al client

, mentre ordinamento sul lato client richiede solo punti 1 e 3 (che sono meno molte risorse).

Se il server deve servire contemporaneamente centinaia di client e i client hanno bisogno dell'intero recordset, allora molto probabilmente l'ordinamento sul lato client sarà più efficiente.

Se il campo è indicizzato, il database può restituire i dati già ordinati da tale indice. Tuttavia, ciò richiederà ulteriori ricerche nella tabella per ottenere gli altri campi.

Inoltre, se non si desidera l'intero recordset ma solo alcuni campi superiori (come in ORDER BY LIMIT o SELECT TOP … ORDER BY), l'intero recorset non dovrà essere recuperato e trasmesso sulla rete. In questo caso, l'ordinamento sul lato del database sarà probabilmente più efficiente.

Answer 5

Per soli 5 mila record, non fa molta differenza, ma lo classificherei nel database; anche se non c'è un indice sul campo, probabilmente è almeno altrettanto veloce che farlo in seguito.

Answer 6

Pro ordinamento nel database:

1. velocità. Se si dispone di un indice sull'ordine in base alla condizione, i database non devono necessariamente essere ordinati, e per le massime prestazioni è possibile utilizzare un indice cluster.
2. Facilità d'uso. Un order by nella query sql è più facile da scrivere e gestire rispetto a un comparatore Java.

Pro ordinamento nell'applicazione:

1. personalizzazione. Forse vuoi ordinare secondo criteri più elaborati, quindi un ordinamento personalizzato in Java sarà più flessibile.
2. Riproducibilità. Se si codifica per database diversi, il loro Collating rules probabilmente differirà. Forse è un problema, e tu vuoi un particolare odering. In Java, è possibile scrivere un Custom Collator per assicurarsi che l'output di tutti i database sia ordinato allo stesso modo.

Answer 7

• di solito estrai solo un sottoinsieme di tali dati? -> un buon design back-end (indicizzazione e/o partizionamento) ti aiuta a estrarre quel sottoinsieme ordinato più velocemente; quindi un "ordine per" sul db è una questione di istanti.
Le tabelle
• contengono sempre poche righe di dati? quindi un "ordine per" sul db è questione di istanti

e anche se non lo si (non può) ottimizzare il database si dovrebbe (quasi) preferire sempre lasciare questo tipo di op.s a L'essere

Answer 8

se si è disposti a tirare tutti i dati in memoria e lavorare con esso nella memoria, qui è una libreria che funziona molto bene per il vostro uso caso

http://casperdatasets.googlecode.com

funziona efficacemente come un tabella in memoria, e consente di eseguire ricerche, filtri e SORTING sui dati, tutto in memoria (e in java). si comporta molto velocemente per il numero di record con cui si sta tentando di lavorare e non è necessario integrarsi con un framework ORM pesante.