Viste o StoredProcedure??

lunedì 31 dicembre 2012 - 17.27

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

Elenco Tags VB.NET | SQL Server 2008 R2

86Marco Profilo | Expert

889 messaggi | Data Invio: lun 31 dic 2012 - 17:27

Buon pomeriggio amici.
una domanda troppo banale per voi ma non per me.

Mi sn avvicinato da poco ad SQL Server e devo dire che ho creato un semplice progettino interfacciato con VB.NET che funziona bene.

Leggendo un buon manuale SQL Server mi sorge un dubbio sulla differenza sostanziale che passa tra una semplice query (storedprocedure) ed una vista.

Ho capito che la Vista (semplice non indicizzata) è una sorta di tabella virtuale ma per quale motivo sarebbe più opportuno preferire una vista ad una query?

In poche parole se devo farmi una select dei record della mia tabella anagrafica che differenza passa tra il fare una storedprocedure "SELECT ... ecc ecc..." ed una vista?

In quale scenario potrebbe essere utile utilizzare una vista piuttosto che una storedprocedure?

Sperando di poter ottenere il Vostro aiuto, come sempre d'altronde, ne approfitto per augurarvi a tutti un buon 2013!

andrestu Profilo | Expert

772 messaggi | Data Invio: lun 31 dic 2012 - 19:00

premetto che non sono un esperto, la prima cosa che mi viene in mente è che FORSE con la vista puoi strutturare la query dinamicamente, e cioè ammettiamo che io devo creare a runtime la stringa che mi fa la query, con la vista posso farlo "SELECT MYVIEW WHERE..." non so se con la SP si può fare... forse si, non saprei

Andrea Restucci - Web Developer

86Marco Profilo | Expert

889 messaggi | Data Invio: mar 1 gen 2013 - 15:41

Intanto grazie... per non credo sia come dici tu

andrestu Profilo | Expert

772 messaggi | Data Invio: mar 1 gen 2013 - 16:18

beh allora se non è come dico io vuol dire che si può formulare una query a questo modo:

"SELECT MY_STORED_PROCEDURE WHERE ... "

mmm sinceramente non ho mai provato ma non mi sembra così "a naso" che possa funzionare...
forse però mi sbaglio, attendiamo il verdetto di qualche esperto.

Andrea Restucci - Web Developer

86Marco Profilo | Expert

889 messaggi | Data Invio: mar 1 gen 2013 - 19:10

Ei ciao.
Avevo letto male.
Effettivamente la select da una vista posso farla come dici tu ma da una stored procedure no.
Il mio "non credo sia come dici tu" era riferito al fatto che non credo che la differenza stia solo in ciò che tu mi hai detto :-).

Ciò che dicevi è effettivamente vero ma ripeto non credo che la differenza tra view e storedp stia solo in quello.

andrestu Profilo | Expert

772 messaggi | Data Invio: mar 1 gen 2013 - 19:56

ok, allora rimaniamo in attesa di qualche info aggiuntive da qualcuno.

Andrea Restucci - Web Developer

86Marco Profilo | Expert

889 messaggi | Data Invio: lun 7 gen 2013 - 22:18

Non c'è nessuno??? :(

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: gio 10 gen 2013 - 14:32

eccomi..
dunque dunque dunque.. discorso molto delicato.
Partiamo da una premessa, la stored procedure è una cosa non paragonabile a query o viste. Quindi direi di non approfondire, perchè ci vorrebbero ore e ore di discussioni sull'argomento

Quindi non compariamole, ma vediamo di capire i vantaggi di una soluzione basata su query/viste rispetto ad una con stored procedure.
Parlo anche per esperienza personale, anche perchè quando si parla di queste cose c'è da stare anche sul "soggettivo".

Perchè una soluzione a stored procedure?
Primo motivo che mi viene, perchè è estremamente modulare, trattandosi di una vera e propria procedura (sottoprogramma) e "chiamabile" in più punti.
Poi, nel caso di refactor/modifica i punti di manutenzione sono centralizzati.
Inoltre previene il sql injection, che non è poco, ma non è l'unica struttura che li evita (mio articolo: http://www.dotnethell.it/articles/SQL-Injection-Tutorial-Security.aspx).
Poi, ci si può legare al motore (linguaggio proprietario t-sql) e non devo preoccuparmi di fare cross platform (mysql, oracle, ..).
Ancora, la security, altamente personalizzabile. E' infatti possibile tenere lontani i chiamanti dal vero e proprio modello (tabelle) per decidere come i chiamanti stessi devono operare sugli oggetti (limiti di profilazione).
E' possibile inoltre aggiungere in esse alcune logiche di business (IF, WHILE, creazione di oggetti temporanei).
Infine, le performance! Il piano di esecuzione calcolato durante la compilazione della stored procedure (sì, è compilata) è in cache e durante l'esecuzione del comando al suo interno, il piano non deve necessariamente essere ricreato, risparmiando quel tempo durante la submit del comando.
Poi potremmo aggiungere.. debug, set di alcune opzioni, gestione transazioni, possono essere .net CLR stored procedure, ecc..

Perchè una soluzione a query/viste?
Voglio decidere dall'applicazione che query lanciare e quindi comporla dinamicamente.
Non mi devo legare al db server e devo supportare mille tipi di database.
Mi posso permettere di dare accesso agli oggetti tabelle/viste.
Voglio usare linq to sql o entity framework al meglio con elasticità.

Detto questo, differenza tra utilizzo di viste o meno.
Sì, quello che dice Andrea è corretto, non posso fare una select from sp, ma posso fare una select from Function (che non è poi così differente a livello di sintassi). Tuttavia, non si può fare, se non con una INSERT tabella EXEC stored_procedure e POI, SELECT campi FROM tabella. Ma questo non è il punto a mio avviso focale. Le viste, oltre a garantire modularità, sono fatte per aumentare il livello di astrazione, tenendo, di fatto, i chiamanti lontani dalle tabelle (sì, anche le sp). Con semplici filtri è possibile fornire SOLO un set di dati all'utente, organizzati in maniera più orientata all'esigenza dell'utente (nascondendo campi per uso interno ad esempio). Inoltre è molto importante se vogliamo fare refactor. Pensate al rinomina di una tabella mentre si lavora (o se si deve rilasciare), può essere un ottimo punto di "appoggio". Inoltre, se usate con le stored procedure, aumentano la modularità, perchè una particolare query (ad esempio "lista dei clienti attivi") verrà di certo riutilizzata in una marea di punti chiave.
Infine, una vista, si comporta come una subquery, il che aiuta il motore durante l'ottimizzazione dello statement.

Però la vista ha degli svantaggi:
- filtri solo con COSTANTI al suo interno
- non si sincronizzano (pensare al select * in una vista, non si sincronizza se le tabelle sotto cambiano)
- non accettano parametri (cosa che una table function invece consente)
- non accettano order by se non con TOP indicato (corretto, mai mettere order by nelle viste, visto che sono subquery)

spero di aver risposto almeno in parte alle domande..
ciao e un buon anno a tutti!

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

andrestu Profilo | Expert

772 messaggi | Data Invio: ven 11 gen 2013 - 13:16

ecco questo è quello che possiamo definire il parere di un esperto !!!
e se prima avevo un solo dubbio ora invece sono molteplici...

Andrea Restucci - Web Developer

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: sab 12 gen 2013 - 18:14

>e se prima avevo un solo dubbio ora invece sono molteplici...

Se vuoi discuterne no problem, io ci sono sempre :)
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

andrestu Profilo | Expert

772 messaggi | Data Invio: sab 12 gen 2013 - 20:35

Grazie Alex,
per il momento anche volendo non ho molto tempo per analizzare nel dettaglio tutte le tue preziose indicazioni, mi tornerà sicuramente utile la discussionre a tempo debito...

Andrea Restucci - Web Developer

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 !