suche nach SQL Schulungsunterlagen

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