Newsgroup: it.comp.lang.visual-basic
Titolo: [?] StoredProcedure, prestazioni e lato C/S. Dubbi.

Non ho elementi di prova (che, naturalmente, non mancherò di procurarmi "sul
campo", ma con comodo, perchè sono perpl[esso|ito|imuto|Null|Nothing|""],
fate voi, al punto di essere persino prevenuto che nulla ha a che fare con
l'eiaculazione precoce), ma oggi pensavo (anche in conseguenza di un odierno
post):
-Se è vero (com'è vero, anche se, IMHO, in modo, pratico e "quotidiano" del
tutto ininfluente, tenuto conto di quel che si deve fare per
preparare/parametrizzare/ottenere/ordinare/esporre/etc., anzi, oserei
persino dire controproducente) che una StoredProcedure (parliamo pure,
esplicitamente, di SQL Server e, quindi, di
Client/Server) è più veloce (per il fatto che è depositata e, quindi,
pre-compilata/validata) di un comando SQL (no, non un Command) che, per sua
natura, potremmo dire "originale", deve essere compilato/validato, allora,
cosa significa _veramente_ "una SP viene eseguita sul server"?
-Ovvero, escludendo MS Access che Client/Server non è (tradotto vorrebbe
dire, in soldoni, che ogni tabella inclusa in una query SQL viene
trasportata, integralmente, sul Client, con traffico di rete sensibile e
successiva elaborazione locale),
quando mai un comando SQL (quindi non una SP) verrebbe eseguito in
qualsivoglia luogo che non sia il Server?
-Quindi, ancora, quali sono i motivi/giustificazioni che tecnicamente
possano spiegare il fatto che una "cosa SQL", in ambiente Cliente/Server,
possa essere eseguita in altro luogo fisico diverso dal Server stesso?
-Infine, sempre e solo per "bencapire" (TM), quale sarebbe la
giustificazione per qualificare positivamente una SP come "elaborata sul
Server" quando questo è/dovrebbe essere, IMHO, già implicito nel concetto di
Client/Server?
Lo so che mi manca qualcosa, lo so, lo so!
Ma il fumo, in genere, infastidisce più dell'arrosto...

non rispodo specificatamente a uno particolare dei punti che hai elencato,
la mia è solo una riflessione.....
io uso una SP quando devo anche scrivere sul db. Mi spiego meglio. Se devo
fare un'SQL, anche enorme, magari, non faccio mai una SP: mi connetto al db,
lancio l'sql come al solito tramite un'adodb.recordset e leggo il tutto.....
quando uso una SP? ti faccio un esempio pratico che ha migliorato di un
fattore 5.6*10^23 il tempo di esecuzione di un mio applicativo. Allora,
parliamo di una procedura di stampa, ok? Praticamente, supponiamo che devo
stampare gli impegni di una certa persona nel periodo luglio-dicembre (6
mesi); su video questa cosa viene rappresenta come una flexgrid grande tutto
lo schermo, con 6 colonne (una per mese). In ogni cella viene indicato con
colori diversi l'impegno (ovviamente dove l'impegno c'è).
Per stampare mi appoggio su una tabella StampaCalendario, strutturata
appositamente. Questa tabella viene svuotata ad ogni stampa, contiene 31
record (uno per giorno) e contiene 6 campi (uno per mese). adesso sto
enormemente semplificando, ma il discorso è questo.
Questa tabella viene (anzi, veniva) riempita da VB, con un do...while
complesso che con .Addnew e .Update popolava la tabella e poi la mandava in
stampa tramite CR.
Stampare una tabella impiegava qualcosa come 10 secondi, ecco, più o meno.
Poi però ho fatto una procedura ancora più complessa, dove dovevo stampare
gli impegni di *più* persone, quindi tutto si moltiplicava. Le procedura
alla fine ci metteva qualcosa come 5-6 minuti, e non è una battuta.
Allora, ho creato una SP apposita, trasferendo la logica del mitico
do...while in istruzioni SQL (INSERT INTO, UPDATE, etc.): la stessa stampa
da 5-6 minuti, ci ha messo qualcosa come 3-4 secondi, E NON E' UNA
BATTUTA!!!!!
scusate il maiuscolo!!!
:-))
morale: uso SP quando la procedura è veramente MOLTO complessa, quando c'è
un traffico di rete in ambedue i sensi (non solo leggo dal db, ma devo anche
scrivere, come il mio caso prima). Penso tra l'altro che nel 90% dei casi
una SP sia assolutamente inutile: le classiche stampe sono semplici SQL con
join e compagnia bella, ma in rari casi questo giustifica la creazione di
una SP.
scusate la lunghezza del post, ma volevo raccontarvi la mia esperienza.....
good coding!!!
-- 
Damiani Liborio Igor
ig...@igordamiani.it
 - 
soft...@igordamiani.it
 - 
idam...@hotmail.com
http://www.igordamiani.it
ICQ : 11847262

 esperienza.....
Hai fatto benissimo.
Qui si programma troppo e si chiacchiera (pur di VB) poco.
A me manca.

sì, ho notato che i tuoi post sono prevalentemente teorici/riflessivi
piuttosto che richieste di codice o simili......
anche io sono fatto così: oddio, ovviamente scrivo codice a valanga, ma ho
una "testa" più riflessiva e discorsiva. magari sbaglio sintassi, ma ragiono
sempre!!!
;-)
cmq, sì, le occasioni per usare una SP sono veramente poche. Vuoi saperne
una? Quando avevo cominciato a scrivere la SP che ho detto prima, non mi
aspettavo certamente un risultato del genere: è stata veramente una
sorpresa!!!!
Volevo studiarmi le SP soprattutto, e non lo nascondo, per fare il "figo",
cioè, poter dire che la mia app gira sotto sqlserver sfruttandone appieno le
potenzialità. Invece, ripeto, è stato un successo quel mio esperimento......
Oggi uso poco le SP, appunto perchè non sempre sono veramente
indispensabili.......anzi.....
credo siano utili quando devi lavorare su centinaia di migliaia di record,
se non di più, oppure per le problematiche dette prima......
tra l'altro, un'altra cosa: la SP serviva per generare tabelle da mandare
successivamente in stampa. Oggi uso i recordset disconnessi, che è ancora
meglio. Le SP per definizione scrivono dati sulle tabelle del server, oggi
ne faccio addirittura a meno. Ho riscritto il famoso do...while
ottimizzandolo di brutto, e salvo su un adodb.recordset che poi do come
datasource al report di crystal report (ebbene, sì, uso questo!!!)   ;-))
questo evita che il db cresca di dimensioni inutilmente, evita di fare lo
shrink del db, evita che il backup del db sia inutilmente lungo, e per un
milione di altri motivi.....


Client/Server?
A proposito di "bencapire" (TM), non ho capito la domanda :-(
-- 
ciao, hal

 A proposito di "bencapire" (TM), non ho capito la domanda :-(
A parte Access che trasporta le tabelle interessate sul client/utente,
quindi ipotizziamo SQL Server, ogni comando SQL (dico/chiedo io) "viene
eseguito sul Server". Che senso ha allora dire (ed è questa la domanda) "Le
SP vengono eseguite sul Server" come se avessero, per questo, un
comportamento diverso, ovvero come se altre cose venissero eseguite a
Timbuctù?

 Timbuctù?
La differenza non sta nel fatto che sono eseguite sul server.
Anche la query che il tuo app passa a sql server viene eseguita sul server.
La differenza sta nel fatto che sono precompilate sul server.
Ciò porta ai vantaggi che ti ha già sottolineato hal e ad altri due che ti
evidenzio io:
- Indipendenza dell'applicativo dal database: altro è passare un nome di sp
ed altro riscrivere alcune chiamate sql particolarmente complesse per sql
server, oracle etc... (vedi il tuo thread sulla standardizzazione della
logica di accesso ai database).
- Separazione dei livelli di elaborazione (o logica di business, se vuoi
usare una dizione cara a ms).
La tua sp può essere condivisa da x applicativi e fare sempre il lavoro
nello stesso modo, manutenuto in un unico punto sul server, invece che in
dieci diversi app.
Questo lo puoi ottenere anche in altri modi, ovviamente, ma le sp sono uno
dei più efficienti.
Che poi non siano "strettamente indispensabili" è vero.
Se la metti così, però, anche un database relazionale non è "strettamente"
indispensabile, no?
ciao
ugo

Timbuctù?
Non ha senso.
-- 
ciao, hal

[*hal1961*=
aldoc...@inwind.it
] ha scritto:
... taglio tutto, ma grazie.
Ora č chiaro e sono d'accordo.
Inoltre non si sconvolge il mondo. E' consolante.

[*Ugo Mangini*=
ugoma...@tiscalinet.it
] ha scritto:
...
Ok, grazie anche a te Ugo. Chiarissimo.