Select-Befehle für wiederholte Benutzung speichern?

[Jürgen Thomas]

Hallo,
der Anwender soll in der Applikation (über eines oder mehrere Eingabeformulare) SELECT-Befehle mit Parametern erstellen und speichern können; bei späterer Gelegenheit soll der Befehl wieder verwendet werden mit anderen Inhalten der Parameter.

Was ist am praktischsten, wo und wie Befehl, Parameter-Name und -Typ sowie Beschreibung zu speichern wären?

1. ausschließlich als Stored Procedure
2. wie eine View in der Systemtabelle RDB$Relations
3. mit eigenen Tabellen in der Datenbank (z.B. RDB$Select und RDB$Parameter)
4. mit eigenen Tabellen in einer Xml-Datei
5. oder gibt es noch andere geeignete Verfahren?

Bei Begründungen und Diskussionen könnt Ihr Euch kurz fassen; ich kann mir die Konsequenzen selbst ausmalen. Danke! Jürgen

[Heffalump]

Ich halte 4. für die beste Lösung. Man kann sicher die Daten auch in der Datenbank halten, aber bei mehreren Benutzern müsste dann noch so etwas wie "Mandantenfähigkeit" für Benutzer eingebaut werden. Dazu gehört auch, wie man sicherstellt, das die Benutzer nicht gegenseitig in die Selects schauen können, usw.. Lösung Nr. 4 un damit in das Profilverzeichnis eines Benutzers.

[mkinzler]

Ich würde 1+2 bevorzugen.

[hoika]

Hallo,

"natürlich" in die DB, egal wie (die XML als Blob z.B.).
Das jeder Nutzer nur seine eigenen sihet (oder die sogar als
"kuck mal, kannst du auch haben", für alle speichert,
ist nur ein bisschen Programmierung.

Zu dem Profilverzeichis,
solange keine servergespeicherten Profile genutzt werden,
könnte der Nutzer ja nicht an einen anderen Rechner gehen
und dort wie gewohnt weiterarbeiten.


Heiko

[Elvis]

Zitat:

Zitat von mkinzler

Ich würde 1+2 bevorzugen.

Ist in Firebird leider nicht wirklich so nett möglich wie es wohl ursprünglich gedacht war, da Firebird weder Schemas noch Packages kennt.
Natürlich könnte man diesen Objekte witzige, vllt zufällig generierte, Namen geben, die in Quotes eingeschlossen sind.

Der Name, den der Benutzer sehen würde, würde dann in den Metadaten stehen.
Da Views in FB ein wenig stiefmütterlich behandelt wurden und selectable SProcs im Vergleich zu anderen DBMS weniger Overhead haben, würde ich in dem Fall für SProcs plädieren.
Macht auch die Parametrisierung einfacher. :)

[Jürgen Thomas]

Danke für alle Kommentare.

Ich habe mich entschlossen, alles (auch variable Inserts usw.) per SProc zu registrieren: Schreibender Zugriff auf die Systemtabellen ist kaum möglich (und natürlich äußerst riskant); aber für SProcs bin ich mit Input- und Output-Parametern hinreichend flexibel.

Jürgen