Query da codice o da Sqlserver?

mercoledì 01 aprile 2009 - 15.19

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

$ilver Profilo | Junior Member

154 messaggi | Data Invio: mer 1 apr 2009 - 15:19

Avrei bisogno di togliermi un dubbio che è il seguente:

Avendo un'applicazione web creata con vb.net visual studio 2008 e sql server 2008, le diverse query, inserimenti, cancellazioni, update dei dati che ho nel db devono essere fatti tramite sqlcommand, cioè da codice, oppure è meglio richiamare delle store procedure e far lavorare sql server?

Perchè è meglio una soluzione rispetto ad un'altra?

Grazie mille a tutti.

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: mer 1 apr 2009 - 15:31

>Avendo un'applicazione web creata con vb.net visual studio 2008
>e sql server 2008, le diverse query, inserimenti, cancellazioni,
>update dei dati che ho nel db devono essere fatti tramite sqlcommand,
>cioè da codice, oppure è meglio richiamare delle store procedure
>e far lavorare sql server?
In entrambi i casi "lavora sql server", ma ci sono motivi per cui la seconda soluzione è migliore:
>Perchè è meglio una soluzione rispetto ad un'altra?

1 - modularità, nel senso che l'sql è all'interno di compartimenti stagni ed è più innestabile/riutilizzabile
2 - manutenibilità, è sicuramente più manutenibile spostare l'sql all'interno di oggetti database che tenerli cablati nell'applicazione
3 - versatilità, oltre ad essere codice riutilizzabile e centralizzato negli oggetti sql server, ti svincola dal dover ricompilare se cambia parte dell'SQL
4 - sicurezza, è più sicuro imporre agli utenti che si collegano determinate permission sui delegati pubblici (le stored procedure in questo caso) che sulle tabelle direttamente, che dovrebbero essere teoricamente invisibili agli utenti se non tramite ogetti pubblici come viste o stored procedure appunto.
5 - performance, le stored procedure mettono in una cache gli execution plan

inoltre è anche comodo a volte avere parte di logica TSQL all'interno delle stored procedure (ad esempio una gestione dell'errore, la gestione delle transazioni, logiche semplici) e non cablate nel codice. E' anche vero che devi fare considerazioni anche sulla possibilità di rendere fruibile la tua applicazione cross database, e in quel caso, a volte, le query da codice potrebbero essere più comode.

Per ora non mi viene altro..
>
>Grazie mille a tutti.
di nulla!

--

Alessandro Alpi | SQL Server MVP

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

$ilver Profilo | Junior Member

154 messaggi | Data Invio: mer 1 apr 2009 - 15:41

Ok quindi modificherò il mio codice

.

Ps per richiamare delle store procedure da codice io ho visto che diverse persone usano i web service, è una cosa utile o posso richiamarle in un altra maniera?

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: mer 1 apr 2009 - 16:04

>Ps per richiamare delle store procedure da codice io ho visto
>che diverse persone usano i web service, è una cosa utile o posso
>richiamarle in un altra maniera?

Web service è un'architettura, esponi un servizio via web, non è per nulla legato all'esecuzione di stored procedure.
In maniera molto semplicistica devi capire prima se ti servono resultset connessi o disconnessi in lettura, poi procedi con i seguenti step:

- crei un connection object in base alla connectionstring che metti nel tuo file .config (e che reperisci con il CofigurationManager)
- crei un command object con la stored procedure che devi lanciare
- aggiungi eventuali parametri alla collezione parameters dell'oggetto command
- esegui e decidi se devi tornare record oppure se devi solo inserire/aggiornare
--

Alessandro Alpi | SQL Server MVP

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

$ilver Profilo | Junior Member

154 messaggi | Data Invio: mer 1 apr 2009 - 17:43

Ok,
quindi in termini di tempo e di velocità eseguire una select da codice o farla eseguire direttamente su sqlserver tramite una stored procedure non cambia niente?

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: mer 1 apr 2009 - 17:46

>Ok,
>quindi in termini di tempo e di velocità eseguire una select
>da codice o farla eseguire direttamente su sqlserver tramite
>una stored procedure non cambia niente?
dipende da vari fattori, di solito la chiamata a stored procedure, se studiata bene è più veloce, ma può succedere che se la sp è veramente ricca di logiche ci si perda per strada ed allora è meglio demandare le singole query alle stored procedure ma le logiche al codice. Esempio classico, devo eseguire un ciclo su una collezione e, per ogni riga, fare qualcosa a database (inserire ad esempio). In questo caso è meglio fare un ciclo a codice e lanciare la sp che inserisce. Non è consigliabile invece fare una sp che al suo interno ha un cursore che, riga per riga esegue insert. SQL Server non è un application server.

--

Alessandro Alpi | SQL Server MVP

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

$ilver Profilo | Junior Member

154 messaggi | Data Invio: mer 1 apr 2009 - 17:56

Perfetto,
quindi faccio delle sp di insert quando devo fare degli insert e delle sp di update e di cancellazione quando devo fare queste cose nella mia applicazione.
Invece, e ti prometto che è l'ultima domanda

, per estrapolare dati da una view e visaulizzarli in una grid, io ora ho fatto con un command object una select normalissima, ma se questa view diventa piena di dati è meglio estrapolare il tutto tramite sp( anche se non so come fare, perchè quando ho bisogno che mi restituisca una tabella usavo le function di sql)?

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: mer 1 apr 2009 - 20:36

>Perfetto,
>quindi faccio delle sp di insert quando devo fare degli insert
>e delle sp di update e di cancellazione quando devo fare queste
>cose nella mia applicazione.
direi di sì, puoi darti una naming convention, io uso ad esempio <schema>.proc_<nometabella_o_nomeoperazione>_[insert|update|delete|get|list]

>Invece, e ti prometto che è l'ultima domanda

, per estrapolare
>dati da una view e visaulizzarli in una grid, io ora ho fatto
>con un command object una select normalissima, ma se questa view
>diventa piena di dati è meglio estrapolare il tutto tramite sp(anche se non so come fare, perchè quando ho bisogno che mi restituisca
>una tabella usavo le function di sql)?
Allora, tu puoi fare la select dalla vista, io per comodità, anche per i punti che ti dicevo prima, preferisco usare le sp e se ho una vista, utilizzarla al loro interno.
il discorso non è che la vista si riempie di dati, anche perchè la vista è una QUERY, una normalissima select. Quindi non si riempie, ma va su più dati di una tabella.
Va opportunamente filtrata e sulle tabelle che la costituiscono vanno creati gli opportuni indici in base alle tue esigenze.
Se fai una select sulla vista e hai molti dati, preoccupati di fare il filtro corretto, e gli indici corretti.
Il fatto di usare una stored procedure, ti dà i vantaggi che ti dicevo prima.
Per ricavare il resultset basta eseguire la select all'interno della stored procedure, e poi, con ADO.Net in modalità connessa o disconnessa (in base alle esigenze) popolare un DataSet o un DataReader nativi, oppure ancora creare una classe con metodi che tornano collezioni usando l'objectDataSource.

--

Alessandro Alpi | SQL Server MVP

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

Torna su

Stanze Forum

Elenco Threads

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 !