SQL Server, viste e stored procedure

[freezone]

Salve ragazzi volevo risolvere un dubbio.
Quale è il metodo migliore per estrarre dei dati da SQL Server.

1) Con query nella pagina ASP

Set objRS = objConn.Execute("SELECT tabella1.*, tabella2.* FROM tabella1 INNER JOIN tabella2 ON (tabella1.IDEsterna = tabella2.ID AND tabella2.campo = 2) WHERE tabella1ID = 1")
Set objRS = Nothing

2) Con Stored Procedure

Set objRS = objConn.Execute("exec sp_1 " & 1) 
Set objRS = Nothing

Dove la stored procedure "sp_1" è

CREATE PROCEDURE sp_1
@ID int,
@campo2 int
     AS
SELECT tabella1.*, tabella2.* FROM tabella1 INNER JOIN tabella2 ON (tabella1.IDEsterna = tabella2.ID AND tabella2.campo = @campo2) WHERE tabella1ID = @ID

3) Una vista "parametrizzata" creata su SQL Server. Ma non so come si fa.

Il provider con cui lavoriamo mi fa notare che è inutile usare una stored procedure se devo fare solo una SELECT. Tenendo conto che ovviamente la query vera è più complessa ed i record sono parecchie migliaia, qual è la soluzione che mi permette migliori prestazioni?
Così in linea generale. Grazie mille ragazzi

[Roby_72]

Più che altro è inutile usare una SP se la query select la fai così:

SELECT tabella1.*, tabella2.*

dichiara i campi che ti occorrono... non prendere tutto (*) ...

Roby

[freezone]

Originariamente inviato da Roby_72
Più che altro è inutile usare una SP se la query select la fai così:

SELECT tabella1.*, tabella2.*

dichiara i campi che ti occorrono... non prendere tutto (*) ...

Roby

Avevo specificato che la query era più complessa. Ho usato questo tipo di query solo per far capire che i parametri da passare non erano solo nel WHERE ma anche nella JOIN.
Il mio dubbio era sul metodo migliore da adottare. Non tanto sulla bontà della query.

[Alethesnake]

Ciao,

Avendo visto solo la query sopra ciò che mi viene da dire è che anche secondo me la SP è inutile, si tratta comunque di una select da eseguire e puoi eseguirla tranquillamente con il metodo execute della connessione.

Una vista parametrizzata non credo si possa fare, al massimo una function che ritorna una tabella, così sai che devi passargli per forza di cose dei parametri (viene qualcosa tipo: SELECT * FROM tua_funzione(par1, par2, ...) )

La query che hai postato tu comunque puoi anche definirla come vista, le clausole che definisci nella on dell'inner join puoi tranquillamente definirle nella clausola where (in questo caso però dai un'occhiata all'execution plan della query, si sa mai che l'engine non decida prima di fare la cross join e dopo di filtrarla..)

[ciucciatiilcalzino]

premesso che non sono un dba, ma nelle varie prove effettuate in questi anni mi è sembrato di capire questo

la store proceduce è più prestante, ovvero più veloce, perchè lavora direttamente la il motre sql, evitando magari problemi con la pagina asp, ma questo cosa comportà? che potrebbe salire molto il carico di sql , io personalmente in alcune occasioni per bilanviare, ho fatto alcune select nelle store e altre nelle pagine.
Questo per distribuire i carichi.....naturalmente ti sto parlando di test miei personali, per esempio ho visto che facendo delle viste a posto di select o store, la situazione non migliorava.
Quando possibile gli insert e gli update li faccio fare alle store.
Una cosa che a volte trovo scocciante, e che se devi fare una cosa a volo la devi andare a modificare in sql server, mentre se devi modificare una select lo puoi fare direttamente nella pagina, quindi io inizialmente faccio delle query normali, poi se tutto gira, le porto in sql server.
Una cosa fondamentale è eliminare *, fare ricerche se possibile su chiavi numeriche (tipo where id=123) e anche le join collegarli su campi numerici