Gestione Giacenze- perplessità

venerdì 28 marzo 2008 - 14.21

albedo Profilo | Junior Member

Una query come questa:
"SELECT MIN (SCARICO_F) AS SC, QUANTITA FROM VENDITE WHERE DATA = " & (data corrente) & " FORNITORE = " & 'un qualche fornitore' & "ARTICOLO = " & 'un qualche articolo'

Quanto tempo impega ad essere processata su un recordset di circa 100.000 record?

E' possibile far sì che il recordset venga scorso dall'ultimo al primo record invece che dal primo all'ultimo?

Grazie

sankyu Profilo | Senior Member

é un po strana come domanda! su che macchina gira il db? ram, processore, harddisk, raid?
per farti un esempio sul mio server che è un dual xeon 2.8 ghz con 2 gb di ram e 5 hdd scsi 15000 giri una query di quel tipo impiega circa un secondo
poi dipende se ci sono indici o no sulla tabella.
se specifichi meglio vedo se riesco ad aiutarti

alx_81 Profilo | Guru

>Una query come questa:
>"SELECT MIN (SCARICO_F) AS SC, QUANTITA FROM VENDITE WHERE DATA
>= " & (data corrente) & " FORNITORE = " & 'un qualche fornitore'
>& "ARTICOLO = " & 'un qualche articolo'
>
>Quanto tempo impega ad essere processata su un recordset di circa
>100.000 record?
come sankyu dice, DIPENDE da MILLE fattori .
Server su cui gira (le caratteristiche), indici, modo in cui la esegui (evitare la concatenazione ed usare le stored procedure se il dbms te lo consente oppure le query parametriche, anche per evitare il sql injection).
E poi dipende su che DBMS gira, con che provider, tante cose..
>
>E' possibile far sì che il recordset venga scorso dall'ultimo
>al primo record invece che dal primo all'ultimo?
Cosa significa questo? Intanto quella query mi sembra scorretta. Utilizzi una funzione di aggregazione e poi non raggruppi per quantita? Prova a spiegarti meglio


Alx81 =)

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi
http://italy.mvps.org

albedo Profilo | Junior Member

Ciao, alx

sto scrivendo (con molta fatica) questo applicativo su di un pc portatile (AMD 64 ATHLON - 512 MB RAM) e facendo un debug la query risulta essere pressoché istantanea nonostante la tabella abbia 120.000 e passa record e la cosa mi è semprata quantomeno bizzarra (mi aspettavo un qualche rallentamento di una decina di secondi).

La tabella non ha indice per due motivi:

1) I Fornitori e gli articoli sono pochi, sono tanti solo i movimenti di vendita
2) La tabelle può venire modificata molto spesso.

Chiedevo se la cosa fosse normale perché non vorrei che una volta compilato la query rallentasse di molto e che la strana velocità che ho riscontrato non dipenda da qualche fattore che mi sfugge.

Ciao

alx_81 Profilo | Guru

>Ciao, alx
Ciao

>1) I Fornitori e gli articoli sono pochi, sono tanti solo i movimenti
>di vendita
In realtà uno lo ha probabilmente, se hai la chiave primaria. E probabilmente è clustered. Ma prima dovrei capire se usi ACCESS, SQL SERVER, MYSQL o altro..


>Chiedevo se la cosa fosse normale perché non vorrei che una volta
>compilato la query rallentasse di molto e che la strana velocità
>che ho riscontrato non dipenda da qualche fattore che mi sfugge.
La velocità di risposta di una query cambierà di sicuro al cambiare di tutti i fattori di cui parlavamo negli altri post.
Quel tempo di esecuzione è decisamente possibile.. ha idea di cosa siano una decina di secondi in più per un database?
Non ci mettono 10 secondi neanche alcune query fatte su milioni di righe e quindi 120 mila righe sono decisamente poche.. I problemi li incontrerai quando aumenteranno.. 10 secondi sono tantissimi per alcune query (ad esempio quelle sul web).
Alx81 =)

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi
http://italy.mvps.org

albedo Profilo | Junior Member

>>Ciao, alx
>Ciao
>
>>1) I Fornitori e gli articoli sono pochi, sono tanti solo i movimenti
>>di vendita
>In realtà uno lo ha probabilmente, se hai la chiave primaria.
>E probabilmente è clustered. Ma prima dovrei capire se usi ACCESS,
>SQL SERVER, MYSQL o altro..
>
>
>>Chiedevo se la cosa fosse normale perché non vorrei che una volta
>>compilato la query rallentasse di molto e che la strana velocità
>>che ho riscontrato non dipenda da qualche fattore che mi sfugge.
>La velocità di risposta di una query cambierà di sicuro al cambiare
>di tutti i fattori di cui parlavamo negli altri post.
>Quel tempo di esecuzione è decisamente possibile.. ha idea di
>cosa siano una decina di secondi in più per un database?
>Non ci mettono 10 secondi neanche alcune query fatte su milioni
>di righe e quindi 120 mila righe sono decisamente poche..
>I problemi li incontrerai quando aumenteranno.. 10 secondi sono
>tantissimi per alcune query (ad esempio quelle sul web).
>Alx81 =)
>
>http://www.alessandroalpi.net
>http://blogs.dotnethell.it/suxstellino
>http://mvp.support.microsoft.com/profile/Alessandro.Alpi
>http://italy.mvps.org

Ciao axl,

Uso Access.

Ho la necessità di conoscere la quantità fisica in giacenza dell'articolo che di volta in volta viene messo in vendita, a questo punto, visto che la quary è molto veloce, semplicemente eseguirò una SELECT SUM(QUANTITA) sulla tabella VENDITE specificando tre condizioni WHERE: data, fornitore e articolo. Esiste un metodo più efficiente? (perconoscere la giacenza di un determinato articolo per fornitore, intendo).

p.s. tra le atre cose, non mi conviene usrae indic perché la tabella vendita viene modificata di continuo.

Ciao

alx_81 Profilo | Guru

>Ho la necessità di conoscere la quantità fisica in giacenza dell'articolo
>che di volta in volta viene messo in vendita, a questo punto,
>visto che la quary è molto veloce, semplicemente eseguirò una
>SELECT SUM(QUANTITA) sulla tabella VENDITE specificando tre
>condizioni WHERE: data, fornitore e articolo. Esiste un metodo
>più efficiente? (perconoscere la giacenza di un determinato articolo
>per fornitore, intendo).
Ma perchè la quantità è nella tabella vendite?
Piuttosto fare una tabella magazzino dove per ogni articolo ho la relativa giacenza. In questo modo fai una select puntuale per articolo e già sai la quantità.
La tabella vendite deve tenere, appunto, solo le vendite.


>p.s. tra le atre cose, non mi conviene usrae indic perché la
>tabella vendita viene modificata di continuo.
In generale un indice ti velocizza di tantissimo una lettura e le scritture non te le rallenta in maniera "consistente".
Dire che se vai a leggere dalle tue tabelle e le prestazioni contano, gli indici vanno fatti lo stesso.
Non credo che sia possibile pensare ad una tabella in cui "inserisci solamente". Altrimenti non ha utilità.
Magari non sovraccaricarla di indici. Fai solo quelli utili (max due o tre in base alle ricerche che dovrai fare) e vedrai che non ci perdi.

Alx81 =)

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi
http://italy.mvps.org

albedo Profilo | Junior Member

La quantità non è nelle vendite, (forse nell'esempio sopra avrei dovuto scrivere 'colli') ad ogni modo, dato che più fornitori possono avere lo stesso identico articolo, capita di sovente che il magazziniere faccia uan errata associazione fornitore - articolo quindi potrei trovarmi nella condizione di correggere l'errore e di riportare in maniera corretta le giacenze fisciche per ciascun fornitore relativamente allo stesso articolo.

Faccio un esmpio:

Il fornitore TIZIO ha in giacenza 20 MAGLIONI

Il fornitore CAIO ha in giacenza 30 MAGLIONI

Vengono effettuate due tarnsazioni di vendita

1) 10 MAGLIONI DI TIZIO VENDUTI A 10 EURO A SEMPRONIO
2) 10 MAGLIONI DI TIZIO VENDUTI A 10 EURO A SEMPRONIO

Le giacenze sono quindi:

TIZIO: 0 MAGLIONI
CAIO: 30 MAGIONI.

Accade però che il magazziniere abbia per errore associato i 10 MAGLIONI della prima transazione al fornitore errato, e che vada quindi corretta l'associazione ARTICOLO - FORNITORE e, conseguentemente la giacenza per i due fornitori, avere cioè:

TIZIO: 10 MAGLIONI
CAIO: 20 MAGIONI.

Ciao.


alx_81 Profilo | Guru

>La quantità non è nelle vendite, (forse nell'esempio sopra avrei
>dovuto scrivere 'colli') ad ogni modo, dato che più fornitori
>possono avere lo stesso identico articolo, capita di sovente
>che il magazziniere faccia uan errata associazione fornitore
>- articolo quindi potrei trovarmi nella condizione di correggere
>l'errore e di riportare in maniera corretta le giacenze fisciche
>per ciascun fornitore relativamente allo stesso articolo.
In questo caso un indice ti velocizza di molto la ricerca sulla tabella VENDITE per rimediare l'errore.
Quindi io lo farei relativo alla condizione di where (quei tre campi) con l'aggiunta della quantità se è l'unico campo della select (SUM(quantita)).
In questo modo disegni un indice di copertura che velocizza ancora di più la tua query, senza impattare poi tanto sugli inserimenti.
In definitiva lo farei.
Access purtroppo quando aumentano i record, dopo un pochino comincia ad aver davvero bisogno di indici, quindi lo farei ad occhi chiusi.
E' comunque corretto che con 120000 righe le query siano ancora così veloci.
Però, giusto a titolo di esempio, potresti provare a creare una tabella identica alla VENDITE inserendo una milionata di record, facendo la query con e senza indice. Lì dovresti notare una differenza decisamente percettibile .
Ciao!
Alx81 =)

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi
http://italy.mvps.org
Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !
Copyright © dotNetHell.it 2002-2024
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5