Benutzer-Werkzeuge

Webseiten-Werkzeuge

Action disabled: source

engine:procedures-background

Hintergrundinformationen zu Engine-Prozeduren

In diesem Kapitel beschäftigen wir uns mit den grundlegenden Möglichkeiten und Funktionsweisen von Engine-Prozeduren, die zum größten Teil auf durch die Datenbank-Software gegebenen Features beruhen - und daher auch allgemein für „Stored Procedures“ (so werden die in der Datenbank gespeicherten Prozeduren genannt) gelten.

Die bereits erwähnte Sprache T-SQL (für „Transact Structured Query Language“), in der die Prozeduren geschrieben sind, ist erste Wahl für Operationen auf Datenmengen, sie läßt aber durchaus viele Eigenschaften von modernen Sprachen vermissen.

Positiver Effekt dieses Umstands ist allerdings die herausragende Ausführungs- Geschwindigkeit der Prozeduren, sowie die (quasi erzwungene) allgemeine und damit gut wiederverwendbare Daten-Struktur.

Einer Prozedur können Daten, mit denen sie „arbeiten“ soll, auf zweierlei Weisen zur Verfügung gestellt werden :

  • Parameter
  • „Input“-Tabellen

Dem Aufrufer können umgekehrt nach einer Ausführung Daten durch die Prozedur geliefert werden, und zwar durch :

  • Ausgabe-Parameter
  • Ergebnismengen
  • Return-Codes
  • „Output“-Tabellen

Die Details zur Über- und Rückgabe von Daten folgen nun in jeweils eigenen Abschnitten.

Parameter

Über Parameter-Werte werden alle Funktionsweisen einer Prozedur („was sie tun soll“) gesteuert, sie reichen jedoch oftmals nicht aus, um sämtliche Daten, die eine Prozedur zur Verarbeitung benötigt, zu übergeben. Das liegt daran, daß nur „einfache“ Datentypen für Parameter unterstützt werden, oder verständlicher formuliert : es gibt keine „arrays“, und es können auch i.d.R keine großen Text- oder Binärdaten (mehr als 16384 Bytes - ursprünglich im ASE 11 sogar nur 255) via Parameter übergeben werden.

Anmerkung : Seit Version 15.7 kann man Variablen vom Typ „text“ in Prozeduren verwenden (und damit bis zu 2 GB übergeben), die Verwendung erfolgt aber nur schrittweise in den kommenden Engine-Versionen und nur an Stellen wo unbedingt nötig. Das hat im wesentlichen damit zu tun, daß durch Verwendung von solchen Parametern der im ASE definierte „procedure cache“ sehr schnell (versehentlich oder absichtlich) gefüllt werden kann, was zum einen zu einem Fehler führen kann und zum anderen die Performance beträchtlicht negativ beeinflußt.

Die bereits erwähnten Einschränkungen hinsichtlich Prozedur-Parameter werden alle durch das Konzept der „Input“-Tabellen kompensiert - mehr dazu aber im nächsten Abschnitt.

Ersatz für „einfache arrays“ gibt es zudem noch über die Möglichkeit, „string“- Parameter zu verwenden, wobei als Werte „Listen von Zeichenketten“ übergeben werden. Diese Zeichenketten sind durch ein vereinbartes bzw. in einem weitern Parameter angegebenes Trennzeichen voneinander separiert. Diese Methode wird in der Engine übrigens recht häufig verwendet.

Kommen wir nun zu einem sehr schönen und praktischen feature hinsichtlich Prozedur-Parameter, nämlich den „default“-Werten. Wird in der Prozedur-Definition für einen Parameter ein „default“-Wert hinterlegt, dann muß dieser Parameter bei einem Aufruf nicht explizit angegeben werden - es wird gegebenenfalls dann nämlich der „default“-Wert verwendet. Dies ermöglicht es sehr einfach, neue Funktionalitäten einzuführen und trotzdem abwärts-kompatibel zu bleiben. Hinweis : „default“-Werte von Prozedur-Parametern sind aus keiner der System- Tabellen direkt ersichtlich, sondern nur aus dem Quelltext der Prozedur. Dieser steht aber in der Engine ja nicht zur Verfügung, weshalb man sich auf die Dokumentation verlassen muß.

An dieser Stelle eine kurze Präzisierung der gewährleisteten Abwärts-Kompatibilität : Parameter von öffentlich dokumentierten Prozeduren…

  • fallen niemals weg,
  • der Parameter-Name ändert sich nicht, und auch
  • das Verhalten aufgrund (einmal dokumentierter) übergebener Werte für die Parameter ändert sich nicht (von Fehler-Behebungen logischerweise abgesehen).

Es können aber in einem Update sehr wohl Parameter hinzukommen, die dann allerdings jeweils mit einem „default“-Wert belegt sind, der das alte Verhalten sicherstellt.

Außerdem kann sich der Datentyp eines Parameters „erweitern“, d.h.

  • bei einem „variablen string“-Parameter - also einem Parameter vom Typ „varchar(n)“ - kann sich die Anzahl Zeichen, die übergeben werden können, erhöhen (auch möglicher Sonderfall : Erweiterung auf Typ „text“), und
  • bei einem „number“-Parameter - also einem Parameter vom Typ „bit“, „tinyint“,„smallint“, „integer“, „decimal“ etc. - kann sich der Wertebereich erweitern.

Ersteres sollte (bis auf vielleicht den Sonderfall der Erweiterung auf den Typ „text“) zu keinerlei Problemen führen, eine Erweiterung von Wertebereichen hinsichtlich Zahlen kann allerdings bei (stark) typsicheren Sprachen wie „Java“ zu Fehlern führen. Anmerkung : Eine Wertebereich-Erweiterung findet eher selten statt, es ist aber grundsätzlich damit zu rechnen, daß dies passieren kann.

Zur Wertebereich-Erweiterung ein klassisches Beispiel : In einer Version X besitzt die Prozedur „mi_DoSomething_Ad“ einen Parameter „@ToggleSomething“ vom Typ „bit“, d.h. es können nur die Werte „0“ oder „1“ übergeben werden. Nach einem Update auf Version „X+1“ ist der Datentyp des besagten Parameters ein „tinyint“, und es können daher ab nun auch die Werte „2“ bis „255“ übergeben werden - wobei aber nur der Wert „2“ erlaubt ist, d.h. höhere Werte führen zum klassischen Fehler „-500“ (für „falsche Parameter“). Selbstverständlich wird bei den Werten „0“ und „1“ das alte Verhalten beibehalten !

"Input"-Tabellen

Um einer Prozedur Daten zu übergeben, die nicht durch Parameter-Werte abgebildet werden können, gibt es genau eine Möglichkeit : durch eine Tabelle.

In der Engine teilt sich dies in folgende Varianten auf :

  • Session-Tabellen in der „tempdb“-Datenbank
  • Permanente Tabellen in der System-Datenbank „tempdb“
  • Permanente Tabellen in einer eigenen Datenbank, nämlich „dstoreifin“

Eine „Input“-Tabelle ist quasi der Ersatz für ein „zwei-dimensionales array von - in einer Dimension - beliebiger Länge“. Und da als Datentyp für eine Tabellen-Spalte „text“ bzw. (für „Binaries“) „image“ zur Verfügung steht (womit man bis zu 2 GB Daten übergeben kann), werden damit die wesentlichen Parameter-Beschränkungen kompensiert (was wie aber bereits erwähnt durch die Einführung von „text“-Parametern im ASE 15.7 zunehmend an Bedeutung verlieren wird).

Temporäre "Input"-Tabellen

Die erste Variante, nämlich die Datenübergabe via Session-Tabellen („echte temporäre“ Tabellen) wird quasi überhaupt nicht verwendet - eines der seltenen Beispiele bei „externen“ Prozeduren ist om_CopyFromTrolleyToOrder_Pu (s. Dokumentation und Anmerkung zum Parameter „@AddOrderContentInformation“) - , und zwar aus zwei Gründen :

  1. Um eine Prozedur erstellen zu können, die auf eine temporäre Tabelle (also eine Session-Tabelle) zugreift, die sie nicht selbst erstellt, muß diese Tabelle vorher existieren - wohl aufgrund der syntaktischen Überprüfung von T-SQL-statements bzgl. einer solchen Tabelle. Dies erschwert insbesondere ein automatisches Erstellen von Update-Skripten natürlich ungemein…
  2. Darüber hinaus stellt sich das bereits im Abschnitt „model und tempdb“ des Kapitels Die "anderen Datenbanken" erwähnte Problem, daß temporäre Tabellen nicht in Transaktionen erstellt werden können.

Die beiden Varianten, über permanten Tabellen zu gehen, werfen natürlich ein recht naheliegendes Problem auf : Mehrere parallel ablaufende Prozeduren müssen sich offensichtlich solche Tabellen „teilen“ (im Gegensatz zu Session-Tabellen, da hätte jeder Aufruf ja seine eigene Tabelle) ! Wie kann man also sauber und vor allem sicher die Daten voneinander trennen ?

Permanente "Input"-Tabellen in "tempdb"

Die permanenten Tabellen in der „tempdb“ besitzen alle eine bestimmte Spalte, nämlich die mit dem Namen „spid“. Der Name rührt von einer (von der eingesetzten Datenbank-Software zur Verfügung gestellten) speziellen Variablen her, und zwar der „globalen, Session-spezifischen“ Variable „@@spid“. Jede Session (die ja durch einen „connect“ via Login und Kennwort aufgebaut wird) erhält eine Datenbank- Server-weit eindeutige Zahl, den sogenannten „server process identifier“.

Liest eine Prozedur Daten aus einer (permanenten) Tabelle der „tempdb“ aus, so berücksichtigt sie immer nur Datensätze, die die Bedingung „spid = @@spid“ erfüllen. Umgekehrt kann man Daten dieser Tabellen nur zur (eigenen) „@@spid“ manipulieren - s. hierzu die Dokumentation der „mi_InsertTemp…“-Prozeduren bzw. der Prozedur mi_DeleteFromTempdbTable.

Permanente "Input"-Tabellen in "dstoreifin"

Wenngleich die Lösung permanenter Tabellen in der „tempdb“-Datenbank recht simpel und auch gut wartbar (es gibt nur sehr wenige, recht allgemein gehaltene Tabellen wie z.B. „OneID“, „TwoIDs“ und „ThreeIDs“) ist, gibt es jedoch zwei zentrale Probleme :

  • Performance
  • Datenübergabe für mehrfach in einer (Gesamt-)Ausführung aufgerufene Prozeduren (scope-Problem)

Das „Performance“-Problem wurde bereits im Abschnitt „dstoreifin, dstoreifout und dstoretempdb“ in Die "anderen Datenbanken“ geschildert. Etwas komplizierter zu verstehen ist das zweite Problem - was übrigens auch bei einer Lösung mittels Session-Tabellen vorhanden ist !

Ein nicht-konstruiertes sondern tatsächlich vorhandenes Szenario aus der Praxis, um das Problem darzustellen, ist der (in der Regel) „customized“ Auftrags-Status- Wechsel durch die Prozedur „_ac_ChangeOrderState“ (s.a. Das "Actions"- Konzept) : Besagter Prozedur müssen durch eine Input-Tabelle (u.a.) die IDs der Auftrags- Positionen übergeben werden. Nun kann es ein bestimmter Status-Wechsel erforderlich machen, daß nur ein Teil der Positionen direkt weiter in einen anderen Status gesetzt werden muß. Dies führt also dazu, daß die Prozedur „_ac_ChangeOrderState“ aufgerufen wird, während sich der erste Aufruf von „_ac_ChangeOrderState“ noch in der Ausführung befindet ! Daraus ergibt sich die Notwendigkeit, die Input-Daten des ersten Aufrufs einer Prozedur trennen zu können von den Input-Daten für einen zweiten Aufruf (oder sogar weiteren Aufrufen) derselben Prozedur, der stattfindet (bzw. die stattfinden), während der erste Aufruf noch nicht abgeschlossen ist !

Eine Lösung dieses Problems bietet eine weitere „globale, Session-spezifische“ Variable : „@@nestlevel“. Alle Tabellen in der „dstoreifin“-Datenbank enthalten daher zwei Spalten :

  • ServerProcessID
  • NestingLevel

Die „ServerProcessID“-Spalte ist offensichtlich die „klarer“ beschriebene Version der „spid“-Spalte der permantenten Tabellen in der „tempdb“. Der „nesting level“ gibt an, auf welcher „Ausführungs-Ebene“ eine Prozedur (oder auch ein „trigger“) aufgerufen wird :

  • „1“ bedeutet einen DIREKTEN Aufruf
  • „2“ heißt, daß die Prozedur innerhalb einer anderen Prozedur aufgerufen wird
  • „3“ gibt an, daß sie in einer Prozedur aufgerufen wird, die wiederum in einer anderen Prozedur ausgeführt wird usw.

Eine weitere, wichtige Funktion der Spalte „NestingLevel“ der Tabellen in „dstoreifin“ ist, Daten vor (i.d.R. versehentlichen) Manipulationen schützen zu können. Durch „trigger“ auf allen Tabellen (analog übrigens auch in den Datenbanken „dstoreifout“ und „dstoretempdb“) ist gewährleistet, daß eine Prozedur niemals Daten einer Schnittstelle manipulieren kann, die…

  • einer Prozedur einer anderen Session oder
  • einer Prozedur auf einer höheren Ausführungs-Ebene (sprich einem kleineren „nesting level“) der gleichen Session

… gehören.

Die Tabellen der „dstoreifin“-Datenbank dienen sowohl „internen“ als auch „externen“ (also direkt aufrufbaren) Prozeduren, wobei zum Einfügen von Daten für letztere immer eigene Prozeduren (deren Name übrigens mit „if_“ beginnt) existieren.

Ergebnismengen

Aufgrund der Architektur und des Berechtigungs-Konzepts sind Prozeduren die einzige Möglichkeit, um an Daten in der Engine zu kommen.

In der Definition einer Prozedur führt eine beliebige „SELECT“-SQL-Anweisung - sofern es sich nicht um die spezielle SQL-Erweiterung der Variablen-Zuweisung von T-SQL handelt (wie z.B. SELECT @SomeID = 17) - dazu, daß die daraus resultierende Ergebnismenge nach dem Aufruf dem Client zur Verfügung gestellt wird.

Prozeduren können daher grundsätzlich beliebig viele Ergebnismengen während ihrer Ausführung erzeugen. Die SmartEngine beschränkt sich aber selbst auf maximal eine Ergebnismenge (ganz seltene Ausnahmen betreffen i.d.R. nur von dbap zu verwendende Prozeduren und in der Dokumentation wird dann explizit auf mögliche mehrere Ergebnismengen hingewiesen, s. z.B. pm_ConsistencyCheck_Ad), da nicht alle Zugriffs-Schichten (wie z.B. die „Sybase- CT“-Funktionen in PHP – Stand 2008) in der Lage sind, damit umzugehen. Diese Beschränkung ist nur selten ein Problem, zumal es noch die Möglichkeit gibt, über Ausgabe-Parameter (s. gleichnamiger Abschnitt) Daten zurückzugeben.

Entgegen sogenannter „Views“ oder direkt auf dem Server ausgeführter „SELECT“- SQL-Anweisungen sind die „Rückgabe-Spalten“ der Ergebnismenge(n) von Prozeduren aber nicht definiert, insbesondere also auch in keiner System-Tabelle einsehbar. Ausnahme wäre eigentlich die Tabelle „syscomments“, in der der Quelltext von Triggern und Prozeduren steht, aber diese Daten sind für Engine-Objekte (ausgenommen „_ac_“-Prozeduren, s. Das "Actions"- Konzept) nicht vorhanden. Zudem ist es oftmals sinnvoll, die Art der Ergebnismenge hinsichtlich Rückgabe- Spalten und Sortierung von Parametern abhängig zu machen.

Aus diesen Gründen enthält die Prozedur-Dokumentation immer eine ausführliche Beschreibung der jeweiligen Ergebnismenge, und man muß sich insbesondere hinsichtlich der Datentypen auf diese verlassen.

Ausgabe-Parameter

Ausgabeparameter von Prozeduren bieten die Möglichkeit, einzelne Werte zurückzugeben. Dazu muß natürlich bereits in der Definition der Prozedur ein solcher Parameter entsprechend deklariert sein, und zwar mit der „out“- oder „output“- Deklarative.

Ausgabeparameter können wie normale Parameter beim Aufruf mit Werten belegt werden - das macht allerdings nur sehr selten wirklich Sinn und wird z. Zt. nirgends verwendet. Ausnahme ist der spezielle Wert „NULL“ - das wird sogar recht häufig verwendet, weil hierdurch i.d.R. eine besonderen Funktionalität wie die Neu-Anlage von Daten gesteuert wird (s. z.B. Output-Parameter „NodeCharacteristicID“ von im_ModifyNodeCharacs_Ad).

Damit der von der Prozedur solchen Parametern zugewiesene Wert auch ausgelesen werden kann, muß beim Aufruf die „out“- oder „output“-Deklarative ebenfalls angegeben bzw. der entsprechende Mechanismus der Zugriffs-Schicht (z.B. ODBC oder JDBC) verwendet werden.

Klassische Verwendung von Ausgabeparametern findet sich beim Anlegen von Objekten wie z.B. Personen oder Artikel-Elementen wieder, nämlich um die ID des neuen Objekts zur Verfügung zu stellen.

Wenn man direkt SQL bzw. T-SQL auf dem Server verwendet (also insbesondere auch in Triggern oder Prozeduren), gelangt man durch Deklaration einer Variablen (vom selben Typ wie der des Ausgabeparameters), die dann im Aufruf verwendet wird, an den Wert.

Beispiel:

declare @OutputVal integer
exec mi_DoSomething_Ad ..., @OutParam = @OutputVal out, ...

Danach würde der Wert in der Variablen „@OutputVal“ zur Weiterverwendung zur Verfügung stehen.

Return-Codes und Meldungen

Nach der Ausführung einer Prozedur steht dem Client immer garantiert (im Gengensatz zu Ergebnismengen) ein bestimmter Wert zur Verfügung, nämlich der sogenannte Return-Code.

Der Return-Code ist eine „integer“-Zahl. Einzig die „0“ steht für eine erfolgreiche Ausführung der Prozedur. Alle anderen Werte sind entweder vom Datenbank-Server oder von der Engine verwendete Fehler-Codes.

Wenn man direkt SQL bzw. T-SQL auf dem Server verwendet (also insbesondere auch in Triggern oder Prozeduren), gelangt man an den Wert des Return-Codes (wie schon bei Ausgabe-Parametern) durch Deklaration einer Variablen vom Typ „integer“ und entsprechender Verwendung im „exec“-Kommando.

Beispiel :

declare @Error integer
exec @Error = mi_DoSomething_Ad ...

Danach würde der Return-Code in der Variablen „@Error“ zur Weiterverwendung zur Verfügung stehen.

Alle Engine-Return-Codes sowie ein zugehöriger (fester) kurzer Klartext sind dokumentiert. Von Prozeduren direkt verwendet werden ausschließlich negative Werte, die zudem kleiner als -99 sind, da Werte zwischen -1 und -99 vom ASE- Datenbank-Server reserviert sind.

Derzeit sind Prozedur-Return-Codes größer als -10.000, wobei die Werte zwischen - 9.000 und -9.999 für „customized“-Prozeduren reserviert sind !

Es gibt sogenannte „Error-Codes“ in (Engine-)Triggern, die bei Fehlern (i.d.R. zusammen mit einer Meldung) geworfen werden. Diese sind ebenfalls dokumentiert und nehmen ausschließlich positive (integer-)Werte an. Da nun in allen Prozeduren eine Fehlerbehandlung bei Daten-Manipulationen (die ja zur Ausführung von Triggern führen können) stattfindet, kann es also vorkommen, daß der Return-Code einer Prozedur auch einen positiven Wert annimmt, nämlich den Error-Code eines Triggers - oder aber auch eines Fehlers vom Datenbank- Server (z.B. bei Index-Schlüssel-Verletzungen) !

Es gibt jedoch zu einigen Codes (insbesondere dem Fehler „-500“) zusätzliche, zur Laufzeit erzeugte Informationen, auch Fehler-Meldungen genannt. Diese Fehler-Meldungen werden innerhalb der Prozedur erzeugt und durch das „print“-Kommando an standard-out ausgegeben. Sie sind per se nicht von Meldungen des Datenbank-Servers (Fehler-Meldungen, die nicht im „errorlog“ des Servers landen) zu unterscheiden. Fehler-Meldungen der Engine enthalten aber i.d.R. zu Anfang immer den Namen der Prozedur, die einen Fehler festgestellt hat.

Außerdem gibt es einige Prozeduren, die ihrer Natur wegen „viele Dinge“ tun - wie z.B. Prozeduren zum Daten-Import - und daher auch einfach nur „debug“-Meldungen erzeugen (wieder durch das „print“-Kommando)

"Output"-Tabellen

Folgendes Problem begründet die Notwendigkeit, ein Konzept von „Output“-Tabellen zu entwickeln : Daten, die eine Prozedur „B“ als Ergebnismenge(n) zur Verfügung stellt, kann eine Prozedur „A“, die „B“ aufgerufen hat, leider nicht (ohne einige „Klinken“) verwenden. Lediglich Daten, die über Ausgabe-Parameter zur Verfügung gestellt wurden, können weiterverarbeitet werden (s. Abschnitte „Ergebnismengen“ und „Ausgabe-Parameter“ dieses Kapitels).

Hauptgrund hierfür ist, daß die SmartEngine ursprünglich den Datenbankserver ASE von Sybase in der Version 11.0.3 unterstützte, in der es eine solche Funktionalität prinzipiell nicht gab. In höheren ASE-Versionen gab/gibt es zwar gewisse Möglichkeiten, aber trotzdem existieren weitere Schwierigkeiten bzw. Einschränkungen :

  • Zur weiteren (sinnvollen) Verwendung von Ergebnismengen müssen ihre Rückgabespalten und deren Datentypen bekannt sein (dieses Problem kann allerdings in höheren ASE-Versionen gelöst werden), was eine Art „exec proc into #tmptab“ nicht wirklich hilfreich macht
  • Die Verwendung muß auch in Transaktionen möglich sein, was durchaus nicht selbstverständlich ist, da ja z.B. eine Lösung über temporäre Tabellen (der Art „exec proc into #tmptab“) ausscheidet (wie bereits im Abschnitt „model und tempdb“ des Kapitels Die "anderen Datenbanken“ erläutert)
  • Auch wenn in der Engine darauf verzichtet wird, daß eine Prozedur mehrere Ergebnismengen bereitstellt, besteht grundsätzlich das Problem der eindeutigen Zuordnung „welche Ergebnismenge man denn haben möchte“

Es bleibt eigentlich nur die Möglichkeit, daß eine Prozedur von vorneherein so geschrieben wird, daß sie ihre Rückgabemenge(n) in (eine) Tabelle(n) schreibt, auf die die aufrufende Prozedur auch zugreifen kann. Genau diese Art von Tabellen nennen wir „Output“-Tabellen.

Wie schon bei „Input“-Tabellen gibt es prinzipiell drei Möglichkeiten :

  • Session-Tabellen (in der „tempdb“)
  • Permanente Tabellen in der System-Datenbank „tempdb“
  • Permanente Tabellen in einer eigenen Datenbank

Die erste Variante wird wegen der im Abschnitt „Temporäre „Input“-Tabellen“ (weiter oben) genannten Probleme nirgends verwendet. Die verbleibenden zwei Möglichkeiten werden in der Engine tatsächlich benutzt, und wir besprechen sie in den folgenden Abschnitten.

Permanente "Output"-Tabellen in "tempdb"

Die bereits im Abschnitt „Permanente ‚Input‘-Tabellen in ‚tempdb‘ “ behandelten Tabellen dienen sowohl der Eingabe/Übergabe von Daten, als eben auch der Ausgabe. Daher wiederholen wir hier nicht nocheinmal die Besonderheiten wie z.B. die Spalte „spid“.

Praktischer Nebeneffekt ist, daß man so quasi eine Art „pipe“-Funktionalität erhält, wie man sie vom Unix- bzw. Linux-Betriebssystem her kennt. Und tatsächlich gibt es eine Reihe von Prozeduren, die man (durch einen Parameter, wie z.B. „OutputIntoOneID“) anweisen kann, die intern ermittelte Ergebnismenge in einer Tabelle der „tempdb“ zu speichern, um danach eine Prozedur aufzurufen, der man Daten über genau dieselbe Tabelle übergeben kann. Klassisches Beispiel ist die Kombination der Ausführung von pm_GetPersons_Conditions_Ad und pm_GetPersonProperties_Ad.

Permanente "Output"-Tabellen in "dstoreifout"

Zunächst sei - um ein erneutes Wiederholen von Erklärungen zu vermeiden - auf den Abschnitt „Permanente ‚Input‘-Tabellen in ‚dstoreifin‘ “ (weiter oben) verwiesen, da der Aufbau aller Tabellen in der „dstoreifout“-Datenbank exakt mit denen in „dstoreifin“ übereinstimmt.

Genau wie bei den „dstoreifin“-Tabellen ist also insbesondere gewährleistet, daß eine Prozedur niemals Daten einer Schnittstelle manipulieren kann, die…

  • einer Prozedur einer anderen Session oder
  • einer Prozedur auf einer höheren Ausführungs-Ebene (sprich einem kleineren „nesting level“) der gleichen Session … gehören.

Ein Unterschied (auch zu „Input“-Tabellen generell) ist jedoch, daß „externe“ (also direkt aufrufbare) Prozeduren keine Tabellen in „dstoreifout“ besitzen. Dazu besteht auch keine Notwendigkeit, denn einer „client“-Anwendung können ja ohne Probleme direkt Ergebnismengen zur Verfügung gestellt werden.

Ein weiterer Vorteil des Konzepts „dstoreifin“ und „dstoreifout“ ist, daß die Ursache von bestimmten Performance-Engpässen aufgrund der Namens-Konventionen (s. gleichnamiges Kapitel) der Tabellen leicht und eindeutig auf eine Prozedur reduziert werden kann. Außerdem sind die Daten in den Tabellen klar interpretierbar, da die Spalten-Namen im Gegensatz zu den (allgemeinen) Namen der (permanenten) „tempdb“-Tabellen auf die Art bzw. Herkunft der Werte weisen.

engine/procedures-background.txt · Zuletzt geändert: 13.11.2014 (Externe Bearbeitung)