suche nach SQL Schulungsunterlagen

[jobo]

Zu Unterlagen kann ich nichts sagen, außer die google Suche zu empfehlen.

zu Pivot und StoredProcs:
Leider fremdeln die meisten DB mit diesen Anforderungen, eine StoredProc ist sicher eine Lösung, aber eben handgestrickt und steif. Auch die, die es können, machen es nicht besonders flexibel. Für eine Visualisierung verwendet man lieber entsprechende Reportkomponenten.*
Ich würde daher in der Verarbeitung so lange wie möglich in Listenform bleiben und dann final per Reportkompo oder SP die Pivot-Transformation machen.
Im Zweifel kannst Du die Pivot-Transformation natürlich auch nach wie vor dem Spreadsheet überlassen. Die können das prima und komfortabel.

Den Performanceaspekt, den Jumpy schon ansprach, solltest Du jedenfalls nicht unberücksichtigt lassen. Also Daten eindampfen, Aggregation usw. per SQL, ggF. SP, Transformation dann je nach Bedarf mit geeigneten Mitteln. Je flexibler das sein muss, desto weniger würde ich es in der DB machen.

* Wenn Du via Client oder sonst wie in der Lage bist, dynamisch SQL zusammenzubasteln, kannst Du einen deutlichen Komfortgewinn realisieren, wenn Du das dann im Falle von FB als Parameter an eine Aggregat bzw. Pivot SP übergibtst.

[Hansa]

Zitat von jobo:

Leider fremdeln die meisten DB mit diesen Anforderungen, eine StoredProc ist sicher eine Lösung, aber eben handgestrickt und steif. Auch die, die es können, machen es nicht besonders flexibel.

Wieso ist das unflexibel ? Es gibt doch Parameter. Ich brauche z.B. einen Vorjahresvergleich über Kunden-Artikel-Statistik. D.h. ich brauche folgende Parameter : Ku.-Nr., Jahr, Vergleichsjahr, VonMonat, von - bis Art.-Nr. usw. In der DB ist dann eine SP, die diese Parameter verarbeitet. Und ich setze sie in meinem Delphi-Programm und fertig ! Die SP hat in der DB halt ca. 150 Zeilen, und ? Du kannst das ganze auch ohne Stored Procedure machen, dann sind die 150 Zeilen eben in Deinem Delphi-Programm. Ergebnis bleibt aber gleich.

[TRomano]

Über den Sinn, oder eben nicht Sinn, von Stored Procedures kann man wie immer stattlich streiten. Letzten Endes entscheidet man, ob man wirklich immer ein Rollout für viele Rechner machen will (bei einer Delphi-Version) oder ob man es nur server-seitig macht (script) ...
Und eventuell eine andere Frage ist es, ob man es in Delphi auch wirklich mit 150 Zeilen (wie im genannten Beispiel) hinbekommt. Ist nicht immer so. Und drittens schätzt man ab, ob es Sinn macht vom Client aus mehrere Statements an den Server zu schicken, oder ob man an den Server sozusagen nur ein paar Parameter schickt und das gesamte Ergebnis zurückbekommt.
So einfach oder kompliziert ist es eben ...

[Lemmy]

Zitat von TRomano:

Über den Sinn, oder eben nicht Sinn, von Stored Procedures kann man wie immer stattlich streiten. Letzten Endes entscheidet man, ob man wirklich immer ein Rollout für viele Rechner machen will (bei einer Delphi-Version) oder ob man es nur server-seitig macht (script) ...

völlig richtig. Oder wenn es beides mal der selbe Aufwand ist seine 1.000 Kunden mit dem Update zu versorgen spielt das dann (fast) keine Rolle mehr. Es kommt also immer darauf an

Zitat von TRomano:

Und eventuell eine andere Frage ist es, ob man es in Delphi auch wirklich mit 150 Zeilen (wie im genannten Beispiel) hinbekommt. Ist nicht immer so. Und drittens schätzt man ab, ob es Sinn macht vom Client aus mehrere Statements an den Server zu schicken, oder ob man an den Server sozusagen nur ein paar Parameter schickt und das gesamte Ergebnis zurückbekommt.
So einfach oder kompliziert ist es eben ...

leider.. bisher hätte ich auch gedacht, dass es recht einfach ist - aber vor kurzem hatte ich einen Fall da war es deutlich schneller einen join über mehrere größere Tabelle "manuell" zu machen, d.h. erst eine Tabelle abrufen und in eine Objektstruktur zu packen, dann die andere Tabelle abrufen und die Daten dann mit denen in der Objektstruktur zusammen führen....

[Hansa]

Zitat von TRomano:

Über den Sinn, oder eben nicht Sinn, von Stored Procedures kann man wie immer stattlich streiten.

Hier wird nicht gestritten. Aber ich sags mal so : wenn ich vor der Frage stehe, eine SP zu schreiben oder 150 Zeilen in Delphi, dann nehme ich die SP. Die brauche ich nämlich nur vorab in IBExpert testen und dann lediglich die Parameter per Delphi setzen.

@Jobo : Wieso soll es bei verkauften Produkten Ärger geben ? Genau darum geht es bei mir. Die Parameter betreffen auch hauptsächlich die Where-Klausel. Die Datenmenge soll ja von Anfang an gering gehalten werden.

Und die 150 Zeilen kommen in meinem Beispiel nur zustande, weil es eben um 12 Monate geht. Ergibt halt solche Konstrukte (hier 1 Monat und das mal 12 + Where + Var.-Deklarationen) :

Code:

    SUM (CASE MONAT WHEN 1 Then
           CASE :WERTTYP
             WHEN 0 THEN MENGE
             WHEN 1 THEN UMSATZ
             ...geht bis 4
           ELSE
             0
         END
         ELSE 0 END) as Mon1,

[Sir Rufo]

Es führt zwar ein wenig weg von den Schulungsunterlagen ...

Die Argumente pro/contra SP bei einem Pivot (bzw. bei einer komplexeren Abfrage) kann ich auf jeden Fall nachvollziehen.

Die beste Alternative ist eigentlich eine Zwischenschicht die eben genau zwischen dem Client und der Datenbank hängt. Ob die Ergebnisse nun über eine SP (weil die sich eben sehr schön auf dem SQL-Server umsetzen lässt) oder aus einer nachgelagerten Verarbeitung (weil sich das nur mit Kopfstand und Salto rückwärts auf dem SQL-Server berwrkstelligen lässt) spielt dann für den Client keine Geige mehr. Der bekommt die Daten im vereinbarten (und mundgerechten) Format und zeigt diese dann an.

[p80286]

Zitat von Hansa:

Zitat von TRomano:

Über den Sinn, oder eben nicht Sinn, von Stored Procedures kann man wie immer stattlich streiten.

Hier wird nicht gestritten. Aber ich sags mal so : wenn ich vor der Frage stehe, eine SP zu schreiben oder 150 Zeilen in Delphi, dann nehme ich die SP.

Da mir vor einiger Zeit eine SP über den Weg gelaufen ist, die Freitext in drei Felder aufgespalten hat (warum Felder da steht doch alles) stehe ich den Verfechtern der SP eher skeptisch gegenüber. Nichts desto trotz "Es kommt darauf an". Wenn Du "nur" Datenverwaltung mit einer DB betreibst, hast Du andere Anforderungen, als wenn Du vor allem Statistik betreiben willst. Willst Du beides machen, dann richte Die DB auch so ein, daß beides gleich gut geht. Alles andere ist sparen am falschen Platz.

Gruß
K-H

P.S.
manchmal geht kein Weg an einer SP vorbei.

[jobo]

Zitat von Hansa:

Wieso soll es bei verkauften Produkten Ärger geben ? Genau darum geht es bei mir. Die Parameter betreffen auch hauptsächlich die Where-Klausel. Die Datenmenge soll ja von Anfang an gering gehalten werden.

Und die 150 Zeilen kommen in meinem Beispiel nur zustande, weil es eben um 12 Monate geht. Ergibt halt solche Konstrukte (hier 1 Monat und das mal 12 + Where + Var.-Deklarationen) :

Code:

    SUM (CASE MONAT WHEN 1 Then
           CASE :WERTTYP
             WHEN 0 THEN MENGE
             WHEN 1 THEN UMSATZ
             ...geht bis 4
           ELSE
             0
         END
         ELSE 0 END) as Mon1,

Ja, das seh ich auch so, Deine 12 Monate sind 12 feste Spalten. Die Datenreduktion erfolgt auch, ob bei der Aggregation jetzt 10 oder 150 Sätze rauskommen, ist ja wurscht, Hauptsache es kommt nicht die unaggregierte Menge zurück.
Ich saug mir mal ein Beispiel aus den Fingern: Der Kunde möchte eine Pivotmatrix des Umsatzes über alle Produktkategorien, die eine bestimmte Umsatzgrenze übersteigen je Filiale. Die Produktkategorien kann er natürlich selber vergeben. Das Ergebnis ist hier in beiden Dimensionen variabel, Anzahl und Name (sagen wir Standort) der Filialen ist beliebig und Anzahl der Kategorien und deren Name auch. Das kann eine SQL Engine nicht direkt, selbst wenn sie eine Pivotimplementierung hat. Also gut, ich kenne zumindest keine.
Und so wird es unkomfortabel und Du landest bei dynamischen SQL, SP oder nicht, wie auch immer.

[Hansa]

Du meinst also, was man machen soll, wenn nicht mal die Struktur des Ergebnisses bekannt ist ? Ja, dann nützt eine fest in der DB befindliche SP natürlich wirklich nichts oder zumindest wenig. So etwas sollte man dann eben tatsächlich in Delphi zusammenbauen, ist am einfachsten. Aber dann auch mit Parametern. Mit den SPs, das sieht bei mir so aus : wenn ich die Anzahl der Tabellen und die der SPs (Stored Procedures) vergleiche, dann muss ich feststellen, das die SPs doppelt so häufig vorhanden sind. Schätze deshalb mal, dass die, die von diesem Wert weit abweichen (z.B. 50 Tabellen und nur 10 SPs), sich mal um die DB kümmern sollten. Ich habe aber auch schon mal gesehen, dass Programm 80 Tabellen braucht und ich keine einzige SP finde. Auf Nachfrage wurde mir dann gesagt, dass sie die tatsächlich nicht verwenden.

Um nicht zu weit abzuschweifen:

http://www.firebirdsql.org/file/docu...grefupd25.html

Da mal selber suchen.

[waldforest]

Hallo,
auch wenn ich nach Schulungsunterlagen suche, bringt mich die geführte Diskussion auch schon weiter, ich hoffe sie geht weiter, oder macht es Sinn ein eigenes Thread einzustellen um sich der Aufgabe separat zu widmen ?