suche nach SQL Schulungsunterlagen

[IBExpert]

von mir auch noch mal ein paar Anmerkungen

1. Es muss am Ende (zumindest bei Firebird) nicht die eierlegende Wollmilchsau in Form einer Stored Procedure sein. Gerade wenn es dynamisch ist, bietet es sich an, aus Delphi heraus modular einen möglichen Stored Procedure Quelltext zusammenzustellen und den dann als execute block auszuführen. Dafür ersetzt man nur die erste Zeile in der Deklaration.

Das bietet die gleichen Geschwindigkeiten wie eine SP, verhindert aber das man sich ein Monstrum schafft, mit dem man alle Fälle abdeckt. Ein Execute Block kann eigene Variablen haben, die Anzahl der Rückgabefelder kann dynamisch sein, man kann GTT benutzen, ohne anderen in die Quere zu kommen, man muss keine globalen Namen definieren, hat den gesamten Sprachumfang von SPs, kann die in IBExpert debuggen usw.

Wenn man Blöcle die dynamisch zusammenstellt, sollte man die am besten einfach in einer Tabelle speichern mit Laufzeit, dann weiss man relativ schnell, wo die eigene Logik vielleicht nicht ganz so doll ist.

Und zum Ausführen reicht in Delphi nahezu jede TxQuery oder TxSQL Komponente, die sich mit einer SQL Property steuern lässt.

2. Zum Thema Speed: Bei großen Datenmengen unterschätzen auch erfahrene Delphi Programmierer den Geschwindigkeitsvorteil, den SP oder Blöcke bringen. Mit sehr viel Glück und optimaler Programmierung kann eine Delphi Anwendung von einem Firebird Server die Ergebnisse von 1000-2000 Operationen pro Sekunde abarbeiten. Operation sind dabei individuelle insert/update/delete/select statements, die ggf. mit unterschiedlichen Parametern ausgeführt werden. In einer SP bzw einem Block sind 50000 bis 100000 Operationen pro Sekunde keine Zauberei.

Ich hab bei diversen Kunden Auswertungen gesehen, die in Grids oder Reporttools gemacht wurden, wo die Laufzeit nicht mehr nur im Bereich von Minuten waren. Die ergebnisidentische Umsetzung als SP/Block war dann oft in wenigen Sekunden fertig.

Das der Speed dann natürlich auch noch möglichst auf datenbankgeeignete Hardware angewiesen ist und nicht durch Virtualisierung und externe RAID Storagesysteme verlangsamt wird, sollte dann eh klar sein (ist es aber meiner Erfahrung nach leider nicht).

[jobo]

@blöcke und sp:
Also wenn ein Select oder View nicht ausreicht (von den Sprachmöglichkeiten), kann man via Block oder SP häufig noch was rausholen, weil es mehr Möglichkeiten bietet, besonders natürlich wenn es um Datenmanipulation auf mehreren Tabellen geht.
Blöcke würde ich gemäß Client /Server Prinzip da nicht unbedingt vorziehen, außer man hat das, was sie tun genauso gründlich geprüft und unter Kontrolle, wie die SP, die man definiert hat. Klar sind sie flexibler und bieten performancemäßig den "Servervorteil" genau wie eine SP, aber sie bergen auch mehr Risiko für Fehler.

Was den Performancegewinn angeht, der ist natürlich potentiell unendlich, wenn es vorher schlecht genug umgesetzt war. Solche Aussagen finde ich nicht unbedingt hilfreich.

Am Ende kann man ja vielleicht auch bunt mischen, wahrscheinlich meinst Du das auch mit "modular".
SP für gesicherte, robuste DM Operationen und Blöcke für flexible (Business)Operationen, die sich für Core OP der definierten SP bedienen.

[mkinzler]

Zitat:

Was den Performancegewinn angeht, der ist natürlich potentiell unendlich, wenn es vorher schlecht genug umgesetzt war. Solche Aussagen finde ich nicht unbedingt hilfreich.

Ein komplizierter Pivot von großen Tabellen, welcher komplett am Client erfolgt, erfordert meist eine signifikant größere Datenmenge, welche übertragen werden muss.

Zitat:

Am Ende kann man ja vielleicht auch bunt mischen, wahrscheinlich meinst Du das auch mit "modular".
SP für gesicherte, robuste DM Operationen und Blöcke für flexible (Business)Operationen, die sich für Core OP der definierten SP bedienen.

Ich vermute mal mit flexibel meinte er eine Pivotabfrage einfach um Felder erweitern zu können.

[jobo]

Zitat von mkinzler:

Zitat:

Was den Performancegewinn angeht, der ist natürlich potentiell unendlich, wenn es vorher schlecht genug umgesetzt war. Solche Aussagen finde ich nicht unbedingt hilfreich.

Ein komplizierter Pivot von großen Tabellen, welcher komplett am Client erfolgt, erfordert meist eine signifikant größere Datenmenge, welche übertragen werden muss.

Ja klar, es geht mir nur um diese Legenden ala nimm eine SP und es rennt. Und die Leute wundern sich, dass die gleichen schlechten Verfahren in einer SP dann auch nicht (viel) schneller sind.

Zitat von mkinzler:

Zitat:

Am Ende kann man ja vielleicht auch bunt mischen, wahrscheinlich meinst Du das auch mit "modular".
SP für gesicherte, robuste DM Operationen und Blöcke für flexible (Business)Operationen, die sich für Core OP der definierten SP bedienen.

Ich vermute mal mit flexibel meinte er eine Pivotabfrage einfach um Felder erweitern zu können.

Ich hatte IBExpert eher so verstanden, dass er von "frei zusammengestellten" Blöcken sprach, entgegen einer überfrachteten AllPurposeSP, unabhängig vom Pivotthema.
Aber das kann er ja vielleicht selber noch erläutern.

[Hansa]

Zitat von jobo:

wie die SP, die man definiert hat. Klar sind sie flexibler und bieten performancemäßig den "Servervorteil" genau wie eine SP, aber sie bergen auch mehr Risiko für Fehler.

Wie meinst Du das ? Logische Fehler können natürlch immer vorkommen, eine SP mit Schreibfehlern gibt es aber nicht, sie wäre dann nämlich gar nicht erst da. Ausnahme : ich baue sie so ähnlich in Delphi nach. Steht da nämlich so etwas drin : SQL.Text := 'Select * frm...' dann wird mein Delphi-Programm durchaus noch laufen, aber sobald das Programm an diese Stelle kommt, dann wird sich Firebird schon beschweren. Wer liefert nun da die Fehlermeldung ? Könnte irreführend werden. Wirds komplexer, dann denke ich es wird besser in DB verfrachtet und auch getestet. Z.B. meine 150-Zeilen Pivot-Tabelle. Mit so etwas mülle ich mir jedenfalls nicht meine Programme zu.

[jobo]

Zitat von Hansa:

Zitat von jobo:

wie die SP, die man definiert hat. Klar sind sie flexibler und bieten performancemäßig den "Servervorteil" genau wie eine SP, aber sie bergen auch mehr Risiko für Fehler.

Wie meinst Du das ? Logische Fehler können natürlch immer vorkommen, ..

Genau, auch in einer SP. Syntaxfehlern meine ich nicht.
Während man als SP Creator aber die Chance hat, das alles genau zu prüfen und via Berechtigungskonzept und Tests gezielt abzusichern, hat man diese Möglichkeit bei Blocks nur in geringem Maße.

Eine SP passt m.E. perfekt zum Client/Server Konzept. Man erschafft und erlaubt nur die Operationen, die gewollt sind, muss ergo auch nur diese testen und kann damit auf der sicheren Seite sein. Das betrifft natürlich vor allem komplexe Fälle.

Wenn dagegen irgendwer im Client irgendwas per Block zusammenschraubt, wird es schwieriger, alles wasserdicht zu machen.

Nun wird nicht alles so heiß gegessen wie es gekocht wird. Redet man von einem Closed Shop System, wo extern höchstens Lesezugriff besteht und nur wenige (eigene) Entwickler dran arbeiten, ist das wahrscheinlich auch nicht so dramatisch.

Aber das Prinzip finde ich trotzdem gut und erstrebenswert.

[p80286]

Meint Ihr nicht, das es jetzt langsam philosophisch wird?
meiner Meinung nach hat IBExpert das wichtigste schongesagt, nutz die DB wenn Du viele Datensätze ver/bearbeiten mußt.

Natürlich kann es notwendig werden EierlegendeWollMilch-SPs zu basteln, wenn auf der Client-Seite die Unterstützung nur marginal ist, aber das ist doch im allgemeinen nicht der Standard.

Gruß
K-H

[jobo]

Zitat von p80286:

Meint Ihr nicht, das es jetzt langsam philosophisch wird?

Vielleicht ja, der TE wollte ja nicht anders
Und philosopisch ja, wenn es das Gegenteil von gängiger Praxis ist.

Ich sag es mal so:
Ich finde es ab und zu sehr, sehr angenehm, wenn ich bei großen DML auf tausendfach geprüfte (Test und Prod) SP zugreifen kann. Ebenso wie die Tatsache, dass gewisse Business Prozesse überhaupt nur mittels dieser SP aufrufbar sind und niemand es umgehen kann.

[Hansa]

Zitat von p80286:

Meint Ihr nicht, das es jetzt langsam philosophisch wird?

Ne, überhaupt nicht. Wir reden ja hier über knallharte softwareteschniche Fragen. Über Gott und die Welt habe ich bisher nichts gelesen. Die Diskussion passt nun nur nicht mehr zum Titel.