Wie user-abhängige Daten an View übergeben

[SneakL8]

Hallo zusammen,

ich habe ne relativ komplexe Abfrage, die von einem Wert abhängt, der je User unterschiedlich ist.

Leider kann ich der View keine Parameter übergeben. Im Netz habe ich gefunden, dass man die Parameter stattdessen mittels einer temporären Tabelle übergeben kann. Das hab ich probiert, scheitere aber.

Was habe ich gemacht:
- Im DataDictionary eine View MyView angelegt: "select x from Tabelle where <dies und das> and UserID = :UserID"
- Im Programm wird die Abfrage "Select * from MyView" gemacht.
- Vor dem Open erfolgt ein Query.ParamByName('UserID').AsString := <UserID>

=> Bringt zwar keinen Fehler bei der Definition, aber bei der Zuweisung des Parameters ist ":UserID" unbekannt.

- Abfrage geändert auf: "select x from Tabelle where <dies und das> and UserID in (select UserID from #CurrentUser)"
- Im Programm zuvor eine temp. Table angelegt mit "create table #CurrentUser (UserID cichar(8)); insert into #CurrentUser values (<UserID>);"

=> ARC meldet einen Fehler (temp. Tabelle nicht bekannt), selbst wenn ich sie mit dem SQL-Tool im ARC anlege und anschließend die View speichere.

Jetzt meine Frage: klappt das nur mit im Programm zur Laufzeit angelegten Views oder gibt es eine Möglichkeit, im DataDictionary eine View anzulegen, der ein vom aktuellen User (bzw. Connection zur DB) abhängigen Wert übergeben wird? Eine SP bringt mich hier auch nicht weiter, weil diese ja auch nicht an den Wert rankommt, oder?

Viele Grüße
Sneak-L8

[p80286]

SQL-Code:

view:
select x,UserID 
from Tabelle 
where dies and das

Abfrage im Programm:
select * from MyView where Userid=:Userid

So sollte es gehen
Gruß
K-H

[SneakL8]

Hallo K-H,

danke für den Vorschlag. Daran hatte ich auch schon gedacht, aber durch die Bedingung UserID = :UserID wird das Ergebnis der View stark eingeschränkt. Dann würde die View doch zunächst ein sehr großes Zwischenergebnis bringen, das zuerst mit der Haupttabelle geschnitten wird, bevor der filter greift. Oder wird das über die View hinweg optimiert?
Bzw. ist eine intern in der View benutzte Tabelle überhaupt von außen ansprechbar.

Zum besseren Verständnis dann doch die Definition der View (die Joins muste ich schon klammern, weil die Optimierung sonst nicht griff):

Code:

select AuftragsNr, UnterAuftrag
  from (Auftrag as a
        join Benutzer as b
             on a.AnlageUserID = b.UserID),
       (GenGruppeBereiche as c
        join GenGruppeUser as d
             on c.GenGruppe_ID = d.GenGruppe_ID)
 where ((a.GenehmigungStatus = 'O' and
         b.Bereichs_ID = c.Bereichs_ID) or
        (a.GenehmigungStatus = 'P' and
         a.AnnahmeStatus = 'O' and
         a.EmpfaengerBereich = c.Bereichs_ID)) and
       d.UserID = :UserID;

Viele Grüße
Sneak-L8

[jobo]

Nun, eine "sehr starke Einschränkung" ist ja immer wünschenswert bei SQL.
"Im View" liegende Tabellen werden natürlich eingeschränkt, auch wenn der Parameter von "außen" angeliefert wird.
Genauer, jedes Feld eine Tabelle, das im View durchgereicht wird, kann als Parameter und damit als mehr oder weniger stark filterndes Element verwendet werden.

Was im View/Select Statement dann wie gefiltert wird, liegt teilweise außerhalb der Einflussmöglichkeiten, das wird vom Optimizer gemacht, der anhand diverse Kriterien einen -seiner "Meinung" nach- best möglichen Abfrageweg plant.

Mit ADS kenne ich mich nicht aus, es wird aber auch soetwas machen.
Du kannst die Wirkungsweise der Parameter (Performance) ganz einfach in SQL direkt auprobieren und mit verschiedenen Viewdefinitionen (Aufbau der Abfrage) experimentieren.

Idr haben viele SQL Tools die Möglichkeit, die Laufzeit der Abfrage anzeigen zu lassen, viele DB, wahrscheinlich auch ADS haben darüber hinaus die Möglichkeit, den Abfrageplan ausgeben zu lassen. Stichwort "EXPLAIN", musst Du mal bei ADS nachschlagen, wie das dort eingesetzt wird.

[TigerLilly]

Du kannst auch für jede User-ID eine eigene View anlegen + im Code je nach User entscheiden, welche View du benutzt.

Aber ich würde K-H folgen. Die Views nehmen ja keine Daten auf - nur die Abfragen.

[Frickler]

Zitat von SneakL8:

Eine SP bringt mich hier auch nicht weiter, weil diese ja auch nicht an den Wert rankommt, oder?

Einer SP kannst Du Parameter übergeben! Ist ein bisschen umständlich, geht aber noch: alle Eingabeparameter werden über die Pseudotabelle __input übergeben und alle Ausgabeparameter über __output. Das sieht dann ungefähr so aus:

Code:

CREATE PROCEDURE test ( 
  UserID INTEGER,
  erstespalte CHAR (10) OUTPUT,
  zweitespalte DATE OUTPUT,
  ...
)
BEGIN
  DECLARE @input CURSOR AS SELECT * FROM __input;
  OPEN @input;
  FETCH @input;

  INSERT INTO __output 
  SELECT erstespalte, zweitespalte FROM blablubb
  WHERE UserID = @input.UserID;

  CLOSE @input;
END;

Aufgerufen wird es z.B. so:

SELECT * FROM (EXECUTE PROCEDURE test(:user)) x

oder auch

SELECT * FROM (EXECUTE PROCEDURE test(4711)) x

(Hinweis zu "x": die durch EXECUTE PROCEDURE abgerufene "Tabelle" muss einen Namen haben)

[SneakL8]

Hallo Frickler,

danke für die Infos zu SP.
Aber diese SP müsste ich dann ja auch in der View verwenden und damit läge der Parameter in der View, an die ich keinen übergeben kann. Oder hab ich was übersehen?

Viele Grüße
Sneak-L8

[jobo]

Also nur weil man 2 gute Dinge kombiniert, SP und View, kommt nicht zwangsläufig was Gutes dabei raus.
Und ja, es gibt Fälle, wo man sich die Möglichkeiten einer SP zu nutze machen kann. Die sehe ich in diesem Fall aber nicht.

Ich verweise auf Beitrag 2. Das sollte ohne Nebenwirkungen funktionieren und entspricht dem normalen Vorgehen.

[SneakL8]

Hallo Jo,

danke für Deinen Hinweis, der Post von Frickler war schneller zu beantworten, daher hatte ich dazu zuerst geschrieben.

Jetzt konnte ich auch Deinen Vorschlag näher ansehen. Hab's ausprobiert. Ja, wen ich d.UserID aus der View mit ausgebe, dann kann ich darüber ebenfals filtern. Scheint auch nicht langsamer zu sein, als wenn die Bedingung direkt in der View angegeben wird. Ich hatte mich zuerst über das Wort "Parameter (von außen)" gewundert.

Aberso funktioniert's prima, auch wenn ich nun immer an die WHERE-Angabe bei der Nutzung der View denken muss - ja, an den Parameter oder ne Temp-Tabelle müsste ich auch denken...

Viele Grüße
Sneak-L8

[himitsu]

Es gibt auch DBMS, bei denen man Parameter an einen View übergeben kann.

Aber meißtens ist es so, dass der View die Daten für alle User gibt und man das Userabhängige dann über das WHERE des äußeren SELECTs rausfiltert.

Zitat von SneakL8:

Aber diese SP müsste ich dann ja auch in der View verwenden und damit läge der Parameter in der View, an die ich keinen übergeben kann. Oder hab ich was übersehen?

Jupp, indem du eben nicht den View verwendest, sondern direkt das Result der SP.
SELECT * FROM YourSP(Params) ,
bzw. siehe #6, falls es in diesem DBMS so gemacht werden muß.

Ich kenn ADS auch nicht, aber andere DBMS erlauben SP in mehreren Sprachen, wo man z.B. auch direkt ein SQL-Statement als Funktionsrumpf angeben kann.
Also die SP nur als eine Art Makro um das SELECT drumrum.