Reporting environment: Best practices

[p80286]

Zitat von Dejan Vu:

..hat alle Queries als ein einziges SELECT Statement, implementiert. Die Reports sind ziemlich komplex und damit auch die Queries

Aus mir unerfindlichen Gründen gibt es da draußen wohl mehrere Leute, die so arbeiten.
U.U. liegt das daran das ein Formular/Statistik/was_auch_immer bestellt wird und auch genau das geliefert wird.
Von Wiederverwertbarkeit hat niemand gesprochen.

Ich persönlich halte nicht viel von SP (wenn ich sie nicht selbst geschrieben habe), hingegen nutze ich Views wann immer es geht, nicht nur um Tabellen zusammen zu fassen, auch um Daten zu trennen z.B. die Personentabelle in Lieferant und Kunden. Das ist zwar nicht die reine Lehre, aber meist einfacher zu handhaben.

Gruß
K-H

[Dejan Vu]

[QUOTE=p80286;1268303..hingegen nutze ich Views wann immer es geht[/QUOTE] Richtig, ich tendiere auch dazu, zumal diese VIEW (z.B. ein Report) auch als Grundlage für weitere Reports dienen kann. Daher vielleicht eher UDF statt SP.

Aber: In einer View kann ich kein Skript unterbringen, d.h. temporäre Tabellen erstellen und übersichtlicher programmieren. Daher bleibt nur die SP/UDF.

[jobo]

Zu Sql Server Spezifika kann ich nichts sagen.

Allgemein:
Jede Tabelle wird per se als View gewraped.Aus dem Report also kein Zugriff direkt auf Tabellen.
Wiederverwendbare Teilmengen werden als eigenständige Views aufgebaut.
„Core“ Informationen werden in „weiten“ Views (Breite & Tiefe) abgelegt (so weit/tief wie nötig).

Reports (+ Varianten) werden nach Möglichkeit auf identische Core Views aufgesetzt, deren Output dann reportspezifisch beschnitten wird.
Core Views gibt es ggF. in mehreren Hierarchiestufen (Aggregationsebenen oder was auch immer, die nicht idealer Weise nicht vermischt werden sollten bzw. erneut rauf/runtergerechnet werden)
Ein „riesen SQL“ finde ich nicht dramatisch, wenn der Report auf nur eine Datenmenge anzeigt. Ist es entsprechend der Punkte oben in sinnvolle Views gegliedert, dann hat man idR eine gute Übersichtlichkeit.
Der weitgehende Einsatz von Views erlaubt natürlich auch, den Report Content relativ bequem zu ändern, ohne den Report selbst anzufassen. So kann man z.B. das zugrundeliegende Datenmodel abändern, ohne die Reports anfassen zu müssen.
Die Notwendigkeit von Temptables habe ich noch nie gesehen / gehabt, alles per View. In dem Zusammenhang: Da es sich ja um eine Reporting DB handelt, böte sich hier im Rahmen des ETL noch die Möglichkeit, von Beginn an abzuspecken und wie der Name sagt zu transformieren.

UDF/SP:
Ich verwende in Views gerne Session Variables (als Parameter), das ist in der Form glaub ich Oracle spezifisch. Ähnliches lässt sich vermutlich per SP / UDF erreichen. Zusätzlich zur normalen View Verwendung, der „von außen“ auf die gewünschten Parameter eingeschränkt wird, hat man die Möglichkeit Parameter „innen“- also in der Viewdefinition-einzusetzen, sofern die entsprechende Entität nicht dargestellt werden muss (oder auch wenn sie dargestellt werden muss, aber einfach eine riesen Selektivität hat).

Indexed Views:
Kenne ich aus Oracle nicht, hier gibt es materialized Views, die man indizieren kann (und die eigentlich keine Views mehr sind). Würde ich bei einer Reporting DB aber auch nicht mit loslegen, erst wenn es echte Performanceprobleme gibt und das ETL Ergebnis nicht weiter verschlankt werden kann.

[Dejan Vu]

So ähnlich habe ich mir das gedacht. Ob bei guten 'Core'-Tabellen (oder Dimensionen) und Fakten noch temporäre Tabellen notwendig sind, wird man sehen. Wenn nicht, sind die SP obsolet. Obgleich ich es charmant finde, jeden Report in einer UDF abzubilden, denn dann bin ich eigentlich auch vom SSRS / Reporting Front-End unabhängig.

[jobo]

noch was vergessen:
Bestehende Reports sind manchmal nicht unbedingt sinnvoll gegeneinander aufgebaut/abgestimmt. Der Kunde wollte es zwar so, weil er "genau das braucht", sie liefern aber nicht unbedingt Ergebnisse, die eine sinnvolle Plausibilisierung untereinander erlauben. Das ist den Kunden manchmal nicht bewusst, und kann bei der Umsetzung des Models schon mal aufs Glatteis führen.

Abgesehen von dem zuvor beschriebenen Vorgehen, finde es hilfreich, so zu bauen, dass man die Ergebnisse der Reports untereinander vergleichbar ausspuckt. Auch wenn der ein oder andere Bereich gar nicht gefragt ist.

[Dejan Vu]

Auch korrekt. Ich pflege in diesen Fällen in einer Tabelle dann z.B. zwei Spalten für eigentlich ein und die selbe Geschichte anzugeben, z.B. 'Gelieferte Menge' und 'Gelieferte Menge nach Paket'.
In einem Paket sind 50 Stück, 20 Pakete geliefert = 1000 Stück. Beim Nachwiegen fällt aber auf, das ein Paket nur 48 Stück hatte => Gelieferte Menge = 998 Stück.

Komissioniert sind 1000 Stück, für die Mehrverbrauchsrechnung sind aber die 998 relevant. So ist es immer nachvollziehbar.