Newsgroup: it.comp.lang.delphi
Titolo: Viste sul server o da client, cosa cambia?

Sto scrivendo un applicativo con delphi 7 e ms sql 2000.
Uso i componenti SDAC di corelab.
Accedo mediante un componente tipo TMSQuery di corelab che permette
anche gli update selettive su alcune tabelle che fanno parte della
query(vista), e in genere lavoro su viste di più tabelle.
Ora mi è sorto un dubbio:
è meglio creare le viste da ms sql e poi richiamarle mediante il
componente TMSQuery con "select * from miavista" oppure creare le viste
al momento che servono specificando il lungo codice nel campo SQl del
componente (nell'applicazione)?
Credo che in termini stilistici (e se il database è ben progettato)
sia meglio creare le viste nell'RDBMS ma in termini di praticità?.
quello che non sò se dal punto di vista delle prestazioni e della
concorrenza con altri utenti cambi qualcosa.
Cosa ne pensate?
Spero di essere stato chiaro.
Grazie

Grazie per l'interesse!

 concorrenza con altri utenti cambi qualcosa
 > Cosa ne pensate?
Per quanto riguarda le stored procedure (non le viste), l'esecuzione di 
una di esse - lato server - ti garantisce che tutte le istruzioni che 
essa contiene vengono eseguite di seguito e senza interruzioni, cioè una 
SP viene eseguita in modo atomico. Per le viste, invece, si tratta 
normalmente di query residenti sul database, quindi a logica magari al 
limite potrebbero essere un po' più performanti poichè ottimizzate 
direttamente dal motore db, ma occorrerebbe fare delle prove con moli di 
dati consistenti, per osservare come cambiano i tempi lato client.
Come strategia generale personalmente preferisco usare le viste quando 
la query è molto complessa e coinvolge molti dati, ma per una
	select *
	from tabella
mi sembrerebbe un po' sprecato. Inoltre, sono tra i pochi che considera 
una vista come /*UNA VISTA*/, ovvero non permetto mai di intervenire 
direttamente sui dati di una view ma solo su quelli delle tabelle 
sorgenti. Sarò fatto all'antica?
	Marco Bortolani
	info @ 
marcobortolani.it

Perfetto parlavo prorpio di questo.
Penso che sia meglio programmare dal lato server le viste.
Quando parlo di  select * from vista intendo fare una selezione su una
vista residente sul server
che coinvolge più tabelle quindi una query complessa e già
ottimizzata.
Il mio dubbio è il seguente:
supponiamo di avere una vista che mi elenca tutti i clienti presenti
nella tabella clienti e altri dati che sono su tabelle di validazioni
collegate con la tabella clienti.
La vista è sul server e mediante il componente TMSQuery posso fare una
select solo sui clienti che mi interessano e fare gli update solo sui
campi della vista che specifico, in fase di design, nel componente
stesso (è questo che mi piace, oltre alla velocità, dei componenti
della Corelab).
Questo lo faccio sempre per le viste che uso spesso, per esempio su
più form; le apro quando mi servono e le chiudo quando non servono,
tenendo traccia in una tabella delle aperture e chiusure così
risparmio memoria, ma sono sempre oggetti creati e presenti.
Ora pensavo se sia anche il caso di creare oggetti e viste a runtime,
almeno per le viste poco usate, in modo da risparmiare ulteriore
memoria e oggetti (è risaputo che l'informatico è un tirchio di
memoria ((RAM)) ).
Ma ne vale la pena?  a scapito della praticità o meglio intendo della
semplicità del codice e dello sforzo fatto per la scrittura dello
stesso?
Grazie

 stesso?
Durante gli anni che ho trascorso a scrivere codice Delphi sono passato 
attraverso diversi stili di programmazione, ciascuno con i suoi pregi ed 
i suoi difetti. All'inzio usavo per le interrogazioni preparare tutti 
gli oggetti query a design time, sia nel caso mi servissero 
costantemente che nel caso mi servissero una sola volta nella vita. Poi 
ho cambiato strada diametralmente ed ho provato a inserire nel codice 
due o tre query senza testo ed a compilarle sempre e comunque a mano, 
imboccato in questa strada da un mio cliente che era solito fare così.
Alla fine ho scoperto l'acqua calda, ovvero che imho il giusto sta nel 
mezzo: anche a livello di performance finali le query compilate insieme 
al resto del programma sono più prestazionali (con Oracle + ADO c'era 
una differenza di parecchi *secondi*), ma ci sono volte in cui è comodo 
usare comunque questa strategia: il caso che devi affrontare cambia di 
volta in volta, quindi sta a te decidere quale strada imboccare.
Di certo però cercherei di ottimizzare l'esecuzione delle query di 
consultazione (es. elenco fatture) a discapito magari di quelle di 
comando (es. le insert)...
Saluti


Grazie della risposta.
Posso dire che la tua ultima risposta dà un peso maggiore a quello che
già pensavo di fare.
Solo per chiarezza ti dico che a design time (nel componente TMSQuery)
al posto di scrivere una select che incorpora più tabelle, quindi con
almeno 2-3 join, e poi filtrarla con parametri, costruisco prima una
view lato server, magari ottimizzata, e poi a design time in delphi
faccio una select di ciò che mi interessa della view (filtro mediante
select);
poi con le proprietà del componente TMSQuery ho la possibilità di
fare gli update/delete/insert solo per esempio della tabella
principale.
In altre parole uso la "view filtrata" come una tabella (inserendo se
necessario anche il codice particolare negli eventi di
update/insert/delete).
In realtà se il progetto è complicato i TMSQuery a design time sono
almeno 20, allora ho creato un sistema che tiene
aperte (attive) solo quelle che in quel momento servono.
Poi ho 3-4 TMSQuery che costruisco al volo per usi meno frequenti.
Ora mi sto dilettando a costruire function e sp lato server, vedremo
come come và e casomai mi farò risentire per consigli su velocità e
praticità.
Grazie di nuovo.