Newsgroup: it.comp.lang.delphi
Titolo: Info DB

Salve a tutti ... e buona pasqua :-)
Vorrei una conferma da voi perche' comincio ad esser preoccupato...
Ho un DB interbase...
In una tabella di 330mila record....
faccio una semplice query...
Select SUM(Totale) From Table1
Where ID_Operatore = "' + sTemp + '"'
La query funziona correttamente, nn e' quello il problema...
Il problema e' il tempo..... Impiega tantissimo tempo, a volte x rispondere 
NULL
Ho letto un po' in giro via google... ma ho trovato solo che bisogna far 
attenzione agli indici x ottimizzare le query...
La tabella in questione ha indici ID (Primary key) , id_operatore, data 
quindi dovrebbe esser a posto
La mia domanda e' ... E' il db che si presta poco a tabella cosě piene? devo 
cambiare DB ?
Grazie 

 Grazie

> La mia domanda e' ... E' il db che si presta poco a tabella cosě piene? 


 qualsiasi tipo d pc ) e' un sempron 3400 1,8 ghz , 4 gb d ram
Rischio di andare OT....
Oltre a suggerirti nuovamente di studiare BENE come si comporta la sum
se becca un NULL e di provare a postare su un ng specifico sui
database (ovviamente in lingua inglese!) ti do altre dritte...
1) se la versione di interbase non e' l'ultimissima, accertati che non
siano segnalati casini se il motore gira su macchine dual core.. Ad
esempio, ci sono leggende *non confermate* su presunti problemi di
rallentamento di MSDE su macchine dual core...
2) se hai fatto pesanti operazioni di inserimento o cancellazione di
record, dovresti provare a ottimizzare il database
Infine, una nota: troppa faciloneria nel dire "cambio db"...
A.

 oggetto della sum č NULL,


 Non capisco xche' e' così meno efficiente
xche coi dbf tu apri i files e il tuo pc va diretto sui file.
Questa cosa e' sicuramente veloce ma poco sicura per piu' di un
motivo..
Tra parentesi, anche il dbf cede il passo al vecchio Btrieve della
Novell.
Bhe, su 386 con 1 mega di ram scarso in dos in rete lan 10net a 10
megabit faceva impressione.
L'ho usato con l'ultima versione di compilatore basic per dos di
Microsoft, il magico 7.1, evoluzione del quickbasic 4.5.
Azz, parliamo dei primi anni 90...sob!! Sono vecchio...
In un db client/server tu *chiedi* ed e' il servizio (o i servizi..)
lato server che ricevono la tua richiesta e la eseguono, restituendo
al client un cursore, ovvero una specie di puntatore al set di record
restituiti dalla tua query.
A.

 exe da clipper a d5 ... i tempi si sono allungati tantissimo, avendo
Sei ancora innamorato del Clipper ?? ecco la risposta 
http://www.cavo.com/
 ...
:D
^_Goblin_^
-- 
Ibis et redibis non morieris in bello
http://goblinland.myminicity.com/

> Sei ancora innamorato del Clipper ?? ecco la rispostahttp://
www.cavo.com/.
..
Ah, si...Ricordo. Fu un buco nell'acqua della CA.
Il parere unanime a livello mondiale fu "..se devo cmq reimparare
imparo il c++..."
A.


Confermo, ricordo anche i tentativi di portare i programmi scritti in 
clipper 5.2 sotto win 3.11 con CA-VO .. e ho ancora nello scaffale 
davanti a me lo scatolone della prima versione di CA-VO ...
Object-Oriented xBase Client/server development
In fatto di manuali non hanno fatto minimamente economia :)


 ha scritto nel messaggio 
news:bb0a09c2-c35e-4710...@b33g2000yqc.googlegroups.com...


> Quindi mi dici che mi devo rassegnare?
Non e' un "rassegnarsi" quanto un "adattarsi al cambiamento".
La cosa importante e' capire che ci sono cose che su un db client/
server fai in modo diverso o addirittura non fai, e idem dicasi per i
db fileserver come paradox e dbf.
Ad esempio, usando sql puoi creare aggregazioni di dati molto
complesse, puoi fregartene di specificare set index o set order....
Ancora puoi impostare vincoli sui campi che impediscono al database di
digerire dati incongrui, hai le stored procedure che pero' non vanno
usate urbi et orbi, secondo me, ma per compiti precisi e specifici e
sopratutto senza far fare loro elaborazioni molto complesse savlo che
non si tratta di operazioni eseguite quando nessun lavora.
Tutti dicono che le stored procedure hanno il vantaggio di essere
eseguite servr side e quindi non c'e' traffico di rete.
Quello che non viene detto e' che le performance generali del sistema
non dipendono *solo* da quello, che se lanci una stored procdure che
smanetta con migliaia di record in join e fa cose spaziali, se il
server (o I SERVER, se hai un cluster...) non sono abbastanza tosti
questa cosa puo' impattare pesantemente sul lavoro degli altri
utenti...
Non hai cartelle condivise, evitando quindi che qualche utente di
cancelli per errore un dbf o un indice o un dbt...
E ti posso garantire che a tutti i sistemisti come si deve viene
l'ulcera quando si parla di cartelle condivise e si mettono di
traverso in ongi modo.
All'inizio e' dura, come per ogni cambiamento, ma col tempo si impara
e si cresce : si chiama ESPERIENZA.
Ad esempio, quelle count che fai tu forse andrebbero fatte a richiesta
e non automaticamente.
Io da utente mi chiedo "a me quei 2 o 3 dati potrebbero non servire
ogni volta...xche devo aspettare per una cosa che non mi serve??"
Google e' geniale...
Solo dopo che hai impostato qualcosa per la ricerca e clicchi il
magico pulsante, sulla destra ti vengono suggeriti dei link.
Ma solo DOPO il click, non prima!
A.

 A.
Si , concordo perfettamente, infatti anch'io prima di un elaborazione chiedo 
la personalizzazione di una ricerca
E mi sta bene... Il problema si presenta quando diciamo hai un obbligo... 
per esempio... oltre ad aver l'elenco dei prodotti venduti in un giorno di 
lavoro voglio sapere anche il totale di quei movimenti... Le mie perplessità 
erano che se non ho venduto nulla... e faccio questa query, capisco che deve 
leggersi il db x vedere se qualcosa matcha, ma credevo che l'esperienza e 
l'innovazione accelerasse questi tempi
Non entrando in merito ai computer in specifico ( una volta lavoravi con 386 
ora se nn hai un dual core 4gb sei fermo ) i tempi x leggere 300mila record 
e dire nn c'e' niente... sono veramente lunghi