suche nach SQL Schulungsunterlagen

[waldforest]

Hallo,
ich möchte mich intensiver mit SQL-Abfragen befassen, die über die Grundlagen hinaus gehen. Im Netz findet man sehr viele Infos zu einfachen Abfragen. Ich suche eine gute Unterlage, ideal mit Fallbeispielen, bei denen es mehr um verschachtelte Abfragen, Auswertungen mit Aggregatsfunctionen geht.

z.B. Umsatz und Absatzauswertungen, Einkaufsplanung auf Basis Historien (z.B. in Wochen und Monatssicht in Bezug auf Summen, Mittel- und Maximalwerte).

Ich würde dies gerne über SQL, oder ggf einer Procedure in Firebird erledigen.Leider habe ich bisher noch nichts wirklich brauchbares gefunden wie man so etwas in Firebird realisieren kann.

In Excel lässt sich die relativ einfach über Pivots realisieren.

Oder geht das nicht und muss es über eine Proc in Firebird abwickeln?

[Lemmy]

Hallo,

das "The Firebird Book Second Edition" hast du schon?

Der Rest: Kommt darauf an: jede Struktur sieht anders aus und erfordert daher eine andere Vorgehensweise. Wichtig ist, dass Du entsprechende Tools verwendest, mit denen Du Flaschenhälse finden kannst (fehlende Indizes, schlechte Joins,..) sprich eine Performanceanalyse für Queries bietet.

StoredProcedure oder nicht: Kommt halt darauf an: Hast Du einen Datenbankserver (d.h. die Datenbank läuft auf einem anderen Rechner) und es ist möglich, dass durch die StoredProcedure die Menge an Daten die übers Netzwerk gehen deutlich eingeschränkt werden können, weil eben Auswertungen auf viele Daten auf dem Server passieren und nur noch wenige Daten übertragen werden, würde die Nutzung einer StoredProcedure schon Vorteile haben.

Grüße

[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:

Zitat von jobo (Beitrag 1320753)

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 ...

[jobo]

@hansa: Wenn es mit einem Parameter getan ist oder mit 2 oder mit 5 usw, ok. Dafür sind die Systeme ja ausgelegt.
Ich meinte speziell die Pivotfunktion und die Umsetzung (wenn sie überhaupt in einem Produkt existiert, bei fb glaub ich nicht), die leider eine explizite Definition (Angabe) der gewünschten Spalten erfordert. Das wiederspricht der Natur einer Liste, die idr beliebig lang ist.
Pivotisiert man bspw. irgendwelche Geldsummen über 12 Monate ist das unproblematisch, weil es (bis auf das 13. Monatsgehalt) wahrscheinlich keine Varianten gibt. Versucht man das gleiche über verkaufte Produkte, sieht es schon ganz anders aus. An der Stelle wird es unflexibel und man ist besser bedient, wenn man das dazu notwendige SQL dynamisch zusammenbaut (und das dann meinetwegen wieder als Parameter übergibt).

[Lemmy]

Zitat:

Zitat von TRomano (Beitrag 1320756)

Ü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:

Zitat von TRomano (Beitrag 1320756)

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:

Zitat von TRomano (Beitrag 1320756)

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

Hier wird nicht gestritten. :warn: 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 ... :stupid:

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:

Zitat von Hansa (Beitrag 1320762)

Zitat:

Zitat von TRomano (Beitrag 1320756)

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

Hier wird nicht gestritten. :warn: 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:

Zitat von Hansa (Beitrag 1320762)

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. 8-) 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. :shock:

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 ?

[Hansa]

Zitat:

Zitat von waldforest (Beitrag 1320774)

Hallo,
...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 ?

Das ist immer besser. Schliesslich ist ja die Frage nach Schulungsunterlagen ziemlich untergegangen. Auch dank meiner Mithilfe. :mrgreen: Formuliere besser die Frage/Titel neu und mache neues Thema auf.

[jobo]

Zitat:

Zitat von waldforest (Beitrag 1320774)

bringt mich die geführte Diskussion auch schon weiter, ich hoffe sie geht weiter

Ok, also meine Kurzfassung zu SP:
Lohnt sich eher, wenn ein statisches Ergebnis (Spaltengerüst) erwartet wird oder
wenn die Sprachmächtigkeit im SP code genutzt werden kann/muss (z.B. für Pivot) oder
wenn so die Datenkonsistenz wegen Normalformverletzung einfacher zu halten ist (insert, update, delete auf mehreren Tabellen plus Prüfungen)

ansonsten tut's vielleicht eher ein View

oder man nimmt tatsächlich eine Zwischenschicht, wie Sir Rufo vorgeschlagen hat (Das endbindet einen natürlich nicht von der Performancefrage bzw. die gilt von der Zwischenschicht aus gegen den DB Server genauso wie vom Client aus)

[Sir Rufo]

So eine Zwischenschicht ist schon Klasse und die damit gewonnene Flexibilität relativiert auch den größeren Initialaufwand für die Zwischenschicht.

Diesen Mehraufwand am Anfang sollte man aber nicht ausser Acht lassen. So eine Zwischenschicht gibt es eben nicht auf Knopfdruck. Und ein einfaches Durchreichen von SQL-Statements ist dann auch keine wirkliche Zwischenschicht, bzw. führt diese eigentlich wieder ad absurdum, denn die Flexibilität ist damit wieder weg.

[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:

Zitat von mkinzler (Beitrag 1320827)

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:

Zitat von mkinzler (Beitrag 1320827)

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.

[jobo]

ot

Zitat:

Zitat von Sir Rufo (Beitrag 1320784)

Und ein einfaches Durchreichen von SQL-Statements ist dann auch keine wirkliche Zwischenschicht, bzw. führt diese eigentlich wieder ad absurdum, denn die Flexibilität ist damit wieder weg.

Das finde ich übrigends ein sehr interessantes Thema, Tuning bei Persistenzframeworks im weitesten Sinne. Hab da leider gar kein Schimmer.

[Hansa]

Zitat:

Zitat von jobo (Beitrag 1320824)

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:

Zitat von Hansa (Beitrag 1320840)

Zitat:

Zitat von jobo (Beitrag 1320824)

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:

Zitat von p80286 (Beitrag 1320911)

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:

Zitat von p80286 (Beitrag 1320911)

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.