ich denke auch, dass es immer darauf ankommt, f�r welche Zwecke man die SP einsetzen m�chte.
Oft ist es doch so, wo die eine Sache Vorteile bringt bringt die andere Nachteile, was die andere Sache wiederum durch Vorteile auf anderem Gebiet ausgeicht (?)
Ein ganz gutes Beispiel sind hierf�r doch die drei grossen datengebudenen Steuerelemente DataGrid, Repeater und DataList..
Auf die Frage, was nehme ich am besten, wird man wohl immer wieder stossen und sinnvolle Entscheidungen lassen sich vorallem einerseits vor dem Hintergrund von Kenntnissen der Spezialit�ten und Schw�chen der entsprechenden Objekte und andererseits nat�rlich im Hinblick auf die eingenen Absichten treffen..
Ich denke, das l�sst sich auf sehr viele andere Bereiche �bertragen
Viele Gr�sse Lars
At 12:37 03.10.2003 +0200, you wrote:
Ich denke, nicht immer. Es kann auch zur Organisatorischen zwecken dienen. So rufe ich zum Beispiel Im Rahmen eines DTS Jobs immer wieder ein SP auf, dass nach dem Import Tabellen zusammenf�hrt. Das lautet eigentlich f�r jede Tabelle bis auf den Tabellennamen gleich. Das ganze mit einem EXEC Kostrukt zu machen, hat mir die Sache unheimlich erleichtert, gerade wenn weitere Importtabellen dazukommen. Da ein solches jeweils SP nur einmal am Tag aufgerufen wird sind verz�gerungen im kaum Messbaren Breeich nun wirklich hinunehmen.
Oft Beschleunigen SPs den Ablauf bereits, weil sie Prozesse zusammenfassen ohne das ein Zwischenspiel zwischen Client und Server stattfinden muss. Und neu Compiliert wird ein SP auch jedesmal, wenn nicht der Vollst�ndige Tabellenname mit Benutzer angegeben wird (z.B. dbo.Tabelle)
Ich fand den Kommentar ehrlichgesagt ein wenig Platt.
Gru�, Andreas
> -----Urspr�ngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Auftrag von [EMAIL PROTECTED] > Gesendet: Freitag, 3. Oktober 2003 06:41 > An: [EMAIL PROTECTED] > Betreff: [Database.asp] AW: Stored Procedures mal wieder :-| > > > > DECLARE @Tbl VARCHAR(30) > > SET @Tbl = @TableName > > EXECUTE 'SELECT * FROM '[EMAIL PROTECTED] > > RETURN > > Der Sinn von Stored Procedures ist es, schnellere Abfragergebnisse zu > erzielen. Das erreicht man nur, wenn der SQL Server bei der > Speicherung der > Stored Procedure wei�, welche Tabellen, Felder usw. betroffen sind. Dann > kann der Code vorkompiliert werden, nur dann gibt es auch die schnelleren > Abfrage-Ergebnisse. Die oben gezeigte L�sung bringt in Hinsicht auf mehr > Performance gar nichts. > > Was spricht dagegen, f�r jede Tabelle eine Stored Procedure zu erstellen? > Dann wird das Ziel erreicht, den SQL-Code in der DB zu speichern, > man erh�lt > einen Performance-Gewinn und kann individuell WHERE- und ORDER BY Klauseln > setzen. > > Tsch��, Joachim Uersfeld > > _______________________________________________ > Database.asp mailing list > [EMAIL PROTECTED] > http://www.glengamoi.com/mailman/listinfo/database.asp
_______________________________________________ Database.asp mailing list [EMAIL PROTECTED] http://www.glengamoi.com/mailman/listinfo/database.asp
--- Eingehende Mail ist zertifiziert virenfrei. �berpr�ft durch AVG Antivirus System (http://www.grisoft.com/de). Version: 6.0.520 / Virendatenbank: 318 - Erstellungsdatum: 18.09.2003
www.zoologie-online.de
Lars Berner Stormcrow-Software Postfach: 110123 69071 Heidelberg
--- Ausgehende Mail ist zertifiziert virenfrei. �berpr�ft durch AVG Antivirus System (http://www.grisoft.com/de). Version: 6.0.520 / Virendatenbank: 318 - Erstellungsdatum: 18.09.2003
