Newsgroup: it.comp.lang.delphi
Titolo: Indici e ordinamento

Ciao a tutti.
Ho un database Paradox7 chiamato database.db nel quale ho definito un indice
secondario chiamato IdNome che punta al campo nome di tale Database.db.
Se poi da Delphi chiamo questo indice, mi si ordina il database in modo
crescente.
Fin qui tutto normale.
Ma come fare per ottenere un ordinamento in modo decrescente?
Grazie.

Ma come fare per ottenere un ordinamento in modo decrescente?
Definisci un altro indice decrescente.
-- 
Andrea Laforgia (
walkie...@libero.it
)
"Usenet is a strange place" [Dennis Ritchie]

 ha scritto nel messaggio
news:3c64d42f...@news.tin.it...


Ma io vorrei farlo da codice.
Allora, ricapitoliamo.  Tu hai una tabella Paradox con un
indice secondario (che quando e' stato creato e' stato
*ascendente*, che e' poi il default).  L'uso di
quest'indice, di conseguenza, comporta un ordinamento
ascendente dei dati.  Tu hai bisogno, anche, di un indice
discendente.  Ora, io non credo che tu voglia *creare*
l'indice da codice, ma solo utilizzarlo.  In questo caso,
crei l'indice da Database Desktop (ricordati di farlo
*discendente*) e lo usi nel programma, alternandolo
all'indice ascendente.


 ha scritto nel messaggio
news:3c69ef64...@news.tin.it...


 del numero dei campi)?
No.
se hai una tabella con 255 campi non puoi creare 255 indici.
Altrimenti ogni volta che aggiungi un record il motore db
per aggiornare tutti quegli indici ti da il tempo di andare a
prendere il caffe...
Cred che prevedere 20 tipi di ordinamento diverso sia
gia' una esagerazione.
Una query del tipo:
select * from tabella where qualcosa = true order by....
usa gli indici se li trova per ottimizzare i tempi 
di ordinamento, ma se l'indice non esiste, i dati vengono
fuori ordinati comuqnue, solo ci si mette + tempo.
Questo è uno dei vantaggi delle query.
Ad una tabella devi dire "usa l'indice x"
Ad un  query dici sono "voglio questi record ordinati per 
questo/i campo/i": sta a lei (o meglio, al motore db...)
decidere il plan, ovvero la tecnica migliore per il recupero
e l'ordinamento dei dati.
Molti db permettono anche di specificare un plan nella query.
vedi nella guida di interbase per alcuni esempi.
Ma la prima domanda è: quanti sono i records nella tabella?
Bye
AS
"Se è Microsoft non funziona"
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 e l'ordinamento dei dati.
Se non ricordo male, usando gli statement SQL con Paradox,
gli indici secondari vengono ignorati.  In ogni caso,
e' molto piu' lento che impostare l'IndexName da codice.
Inoltre, l'order by non ti consente di modificare i dati,
anche se la query e' request live.  Inutile, per Paradox
e' senza dubbio meglio la TTable.


 Inutile, per Paradox e' senza dubbio meglio la TTable.
Visto la storia degli indici secondari credo tu abbia ragione.
Ma poi, se cambi db....
Bye
AS
"Se è Microsoft non funziona"


Ma poi, se cambi db....
Siamo realisti: quando si cambia DB si cambia
l'applicazione.  Devo ancora vedere qualcuno che e' riuscito
a passare da un DBMS all'altro senza toccare una riga di
codice.  Passando a IB, per esempio, non usi certo le
TQuery, ma ottimizzi il tutto per Interbase, usando i
componenti diretti.


 ha scritto nel messaggio
news:3c66201...@news.tin.it...


 componenti diretti.
Si.
Ma un conto è cambiare l'oggetto di accesso ai dati ed un conto
è cambiare la LOGICA di accesso ai dati.
Esistono differenze tra Tquery, TAdoQuery TIbQuery etc, ma non vanno
a incidere + di tanto sulla logica.
Ma se hai un TTable e devi passare ad una TIbQuery, credo che il
salto in questo caso comporti modifiche al codice nettamente superiori
rispetto al caso precedente.


è cambiare la LOGICA di accesso ai dati.
La LOGICA di accesso ai dati e' sempre la stessa, proprio
perche' entrambi i componenti derivano da TDataSet.  Prova a
scrivere un'applicazione basata solo su statement SQL con
Paradox e vediamo se hai le stesse performance che con i
metodi del TDataSet.  Se intendi semplicemente rimpiazzare
le TTable con le TQuery, ma limitandoti ad usare i metodi
del progenitore comune, allora siamo d'accordo, ma puntare
all'uso di SQL, con Paradox, non e' conveniente.


 ma puntare all'uso di SQL, con Paradox, non e' conveniente.
Lo hai detto + volte e ti credo.
