View, Stored Procedure oder doch Abfrage?

[PASST]

Hallo allerseits,

ich habe eine Verständnisfrage, die sich weniger auf Delphi sondern mehr auf das Design der DB bezieht.

Ich lasse eine Auswertung über eine recht komplexe Abfrage mit 250 Zeilen erstellen. Ich könnte diese Abfrage jetzt in Delphicode packen, halte es aber für besser, dies direkt in der DB einzutragen.

Als View kann ich sie nicht eintragen, da ich mit drei Parametern arbeite. Also bleibt doch eigentlich nur eine Stored Procedure. ODer was meint ihr dazu?

Gruß,
Peter

[hoika]

Hallo,

SPs sind immer die 1. Wahl (geringerer Traffic, Wiederverwendbarkeit usw.).
Aufwändig finde ich aber die Pflege bei Änderungen,
gerade wenn man mehrere Kunden hat.


Heiko

[joachimd]

Zitat von PASST:

Ich lasse eine Auswertung über eine recht komplexe Abfrage mit 250 Zeilen erstellen. Ich könnte diese Abfrage jetzt in Delphicode packen, halte es aber für besser, dies direkt in der DB einzutragen.

Als View kann ich sie nicht eintragen, da ich mit drei Parametern arbeite. Also bleibt doch eigentlich nur eine Stored Procedure. ODer was meint ihr dazu?

Falls die Plattform auf Win32 beschränkt ist, kannst Du das ganze auch als Delphi-DLL in einer Stored Procedure hinterlegen.

[shmia]

Zitat von PASST:

Als View kann ich sie nicht eintragen, da ich mit drei Parametern arbeite

Kommt drauf an.
Man kann ja einschränkende Filter per WHERE-Bedingung auch noch später in der Anwendung setzen:
SELECT * FROM View_Irgendwas WHERE Tabelle1.Feld1=:Feld1 AND Tabelle2.Feld2=:Feld2 Es hängt eben von der Struktur deiner Abfrage ab, ob dieser Weg funktioniert.
Wann immer möglich sollte man Views gegenüber Stored Procedures bevorzugen, da Views viel leichter
auf ein anderes DBMS portiert werden können.
Ausserdem sind Views in der Anwendung pflegeleichter, da sich Views im Prinzip wie normale Tabellen verhalten.
Bitte jetzt nicht falsch verstehen; Stored Procedures haben viele Einsatzgebiete, die man mit Views überhaupt nicht erreichen kann.

[PASST]

Im Grunde geht es mir auch darum, unabhängig von Delphi zu sein, insofern möchte ich diese Abfrage in der DB speichern.

[nahpets]

Hallo,

kannst Du uns die Abfrage mal hier zeigen, eventuell fällt dann eine Entscheidung leichter.

Geht es um eine komplizierte Abfrage über mehrere Tabellen, bei der nur ein Teil der Where-Bedingung variabel ist, sprich über Parameter gesteuert wird? Dann ist shimas Vorschlag die beste Wahl, da eine Viewdefinition relativ leicht von einer Datenbank auf eine andere portiert werden kann (sofern sie nicht zu abgefahren ist). Die Unabhängigkeit von Delphi (oder jeden beliebigen anderen Client) bleibt bestehen.

[PASST]

Hm, so im Detail will ich diese Abfrage jetzt nicht offenlegen. Es geht um ein Rechnungsausgangsbuch unserer noch in XBase++ programmierten Anwendung. Ich bau die Abfrage aber mal beispielhaft nach:

SQL-Code:

select rechnungsdatum, rechnungsnummer, kunde, waehrung,
round(sum(case when typ='WARE' then wert else 0 end)) as [ware],
round(sum(case when typ='VERPACKUNG' then wert else 0 end)) as [verpackung],
..., mwst_einfach, mwst_voll, sum([ware] + ... + mwst_voll) as [brutto]
from
(select rechnungsdatum, rechnungsnummer, kunde, waehrung, typ, waehrung, wert, (wert * mwst), mwstart
from
(select rechnungsdatum, rechnungsnummer, kunde, waehrung, waehrung, 'WARE' as [typ],
sum(einheiten * preis + ... + case when irgendwas then ... else ... end) as [wert]
from auftrag
where ...irgendwas...
group by ...

union

select rechnungsdatum, rechnungsnummer, kunde, waehrung, waehrung, 'VERPACKUNG',
sum(einheiten * preis + ... + case when irgendwas then ... else ... end)
from auftrag
where ...irgendwas...
group by ...

union
...insgesamt 8x...
) subalias1
where printdate >= convert(:vondatum, sql_date)
and printdate <= convert(:bisdatum, sql_date)
and firma = :fma
and wert <> 0
) subalias2
group by firma, rechnungsdatum, rechnungsnummer, kunde, waehrung
order by firma, rechnungsdatum, rechnungsnummer

Vielleicht hat ja jemand eine Idee?

Gruß
Peter

[nahpets]

Hallo,

View draus machen:

SQL-Code:

create view DasIstAberGanzSchoenVielSQLOderSo as
select rechnungsdatum, rechnungsnummer, kunde, waehrung,
round(sum(case when typ='WARE' then wert else 0 end)) as [ware],
round(sum(case when typ='VERPACKUNG' then wert else 0 end)) as [verpackung],
..., mwst_einfach, mwst_voll, sum([ware] + ... + mwst_voll) as [brutto]
from
(select rechnungsdatum, rechnungsnummer, kunde, waehrung, typ, waehrung, wert, (wert * mwst), mwstart
from
(select rechnungsdatum, rechnungsnummer, kunde, waehrung, waehrung, 'WARE' as [typ],
sum(einheiten * preis + ... + case when irgendwas then ... else ... end) as [wert]
from auftrag
where ...irgendwas...
group by ...

union

select rechnungsdatum, rechnungsnummer, kunde, waehrung, waehrung, 'VERPACKUNG',
sum(einheiten * preis + ... + case when irgendwas then ... else ... end)
from auftrag
where ...irgendwas...
group by ...

union
...insgesamt 8x...
)
where wert <> 0
) subalias2
group by firma, rechnungsdatum, rechnungsnummer, kunde, waehrung
order by firma, rechnungsdatum, rechnungsnummer

Abfrage sähe dann so aus:

SQL-Code:

Select * from DasIstAberGanzSchoenVielSQLOderSo
where printdate >= convert(:vondatum, sql_date)
and printdate <= convert(:bisdatum, sql_date)
and firma = :fma

wenn:
where ...irgendwas... nicht variabel ist.

Bei genauerem Detailwissen zu dem Aufbau Deines SQL's könnte man eventuell auch noch entscheiden, ob der 8x vorkommende Block nicht auch in eine View ausgelagert wird und dann zur Laufzeit ein Konstrukt wie

SQL-Code:

select 'VERPACKUNG', * from AchtMalView
where 'die Einschränkung' = 'für Verpackung ist'

benutzt werden könnte.

SQL-Code:

select rechnungsdatum, rechnungsnummer, kunde, waehrung,
round(sum(case when typ='WARE' then wert else 0 end)) as [ware],
round(sum(case when typ='VERPACKUNG' then wert else 0 end)) as [verpackung],
..., mwst_einfach, mwst_voll, sum([ware] + ... + mwst_voll) as [brutto]
from
(select rechnungsdatum, rechnungsnummer, kunde, waehrung, typ, waehrung, wert, (wert * mwst), mwstart
from
select 'VERPACKUNG', * from AchtMalView where 'die Einschränkung' = 'für Verpackung ist'
union
select 'WARE', * from AchtMalView where 'die Einschränkung' = 'für Ware ist'
union
... und noch die übrigen ...
)
group by firma, rechnungsdatum, rechnungsnummer, kunde, waehrung
order by firma, rechnungsdatum, rechnungsnummer

Auch hieraus ließe sich noch eine View machen, auf die dann per

SQL-Code:

Select * from
where printdate >= convert(:vondatum, sql_date)
and printdate <= convert(:bisdatum, sql_date)
and firma = :fma

zugegriffen wird. Je nach Komplexität der mehrfachvorkommenden Union-Teiles kann das die Wartung deutlich vereinfachen. Es muss dann nicht mehr in jedem Union-Teil geändert werden, sondern nur noch einmal in der entsprechenden View.

Das kann man aber letztlich nur bei vollständiger Kenntnis der Abfrage sinnvoll entscheiden.

[PASST]

Die Variante den größten Teil in einen View zu packen, wie du es geschrieben hast, habe ich auch schon gemacht.
Ich frage mich, ob ich diesen Teil, dann nicht in eine Stored Procedure packen kann/sollte/darf:

SQL-Code:

Select * from
where printdate >= convert(:vondatum, sql_date)
and printdate <= convert(:bisdatum, sql_date)
and firma = :fma

[nahpets]

Hallo,

soll denn die ganze Arbeit auf die Datenbank ausgelagert werden, sprich: Benötigst Du keine Ergebnisse im Programm?
Wenn Du das Ergebnis im Programm benötigts, dann ist an dem letzten SQL durch Auslagerung... nix mehr zu verbessern. Einmal müssen die Paramter an die Datenbank gegeben werden und das Ergebnis abgeholt werden.
Und mit weniger Aufwand und pflegeleichter als dem "verbliebenen" Select, wirst Du es nicht mehr hinbekommen.

Einen Bedarf / eine Notwendigkeit, das verbliebene Select noch in eine Stored Procedure zu packen, sehe ich nicht.