Reports allgemein Datentrennung

[haentschman]

Hallöle...8-)
Beim Lesen dieses Threads http://www.delphipraxis.net/187646-f...l-abfrage.html viel mir eine provokante Frage ein. Unabhängig davon das das funktioniert...

[Provokation ON]
Mit welchem Recht hat ein Report sich selbst Daten zu besorgen und im schlimmsten Falle sogar die DB (Quelle) zu kennen?
[Provokation OFF]

In der GUI schreien alle immer gleich nach Trennung zu den Daten. :thumb: Warum nicht auch im Report? Den Report hat es doch nicht zu interessieren wo die Daten herkommen und in welcher Form sie zur Verfügung stehen. :gruebel: Der Report hat von mir aus als "Schnittstelle" Datasets. Wie und woher die gefüllt werden ist dem Report doch wurscht... :P Der Report bekommt Daten und macht ein Bild daraus. Für etwas anderes ist er nicht da...

Fröhliches diskutieren...:thumb:

[Bambini]

Zitat:

Zitat von haentschman (Beitrag 1324812)

Für etwas anderes ist er nicht da...

Weil man immer einen Kunden hat, der nicht nur x möchte, sondern auch noch y und z.
Wenn die Daten nur die Applikation "besorgen" kann, kommt man an Mini-Updates nicht vorbei, die nur dem Report die Daten liefert. Wenn man das Scripting seitig löst, kann sich jeder austoben ohne Update :-D
Eine super Sache, ich geben via Scripting sogar den Zugriff auf das Objekt-Model.

[Der schöne Günther]

Habe ich bislang immer so gemacht- Der (Fast-)Report bekommt eine Handvoll (Array, IEnumerable) Objekte, kein TDataSet oder sonst was. Das kann er sich dann in sein TFrxUserDataSet legen um dadurch zu iterieren oder sonstwie verwursten. Ich sehe ehrlich gesagt auch keinen Grund weshalb der Report (Anzeige) selbstständig in irgendwelchen Daten rumwühlen sollte.

Wenn der Kunde selbst aber schon eine fertige Datenbank bereitstellt und von der Software auch noch erwartet, die Reports (zu speziell dieser Datenbank) etwas anpassen zu können, dann habe ich da ehrlich gesagt keine Hemmungen.

[p80286]

Kommt darauf an wie Du "Report" definierst. In den allermeisten Fällen sollte es schon richtig sein, daß da eine Sammlung von Datensätzen geliefert wird, die der "Report" aufhübscht. Wenn aber der Report aus Serienbriefen besteht wo zu einer Person 1..ganz viele Datensätze die auch noch bis zu 4 unterschiedliche Strukturen haben können, dann ist es effizenter wenn der "Report" sich seine Daten selbst holt. Sonst müßtest Du eine riesige Tabelle zur Verfügung stellen, aus der sich der Report mühsam die Daten für den jeweiligen Fall heraus klauben müßte. Und das macht ganz wenig Spaß.
Was ist jetzt daran soo schlimm ist, daß der Report die Quell-DB kennt?
Die Daten werdennatürlich von einem View und oder einer Funktion geliefert, und das Login erfolgt auch nur über eine "dumme" UID.

Gruß
K-H

[mm1256]

Hallo,

einen Report physikalisch unabhängig von einer Datenbank oder einer sonstigen Datenquelle zu erstellen, ist eigentlich ein alter Hut. Zumindest bei List&Label den ich schon seit etwa 18 Jahren verwende.

Man deklariert hier seine Variablen und Felder für den Ausdruck manuell. Woher die Daten kommen, ist dem Report total egal. Das kann prinzipiell alles sein. Diese Unabhängigkeit (und natürlich die damit verbundene Flexibilität) ist bzw. war für mich auch damals das entscheidende Argument für den Einsatz von List&Label.

Natürlich gibt es auch Datenbanksensitive Komponenten, mit denen man dann auf die Schnelle einen Report über einen oder mehrere Tabellen erstellen kann. Aber, das habe ich noch nie verwendet, weil ich eben die Flexibilität schätze, und auch anwende.

Ein Beispiel: Bei TDateTime-Feldern deklariere ich diese für den Report natürlich als entsprechende Variable, und zusätzlich davon noch als numerische Variable Jahr, Monat, Tag, Stunde und Minute. Wenn ein Kunde dann beispielsweise einen Report über alle Rechnungen in einem Jahr/Monat/Tag erstellen möchte, wählt er einfach den entsprechenden Filter, und ich muss keine "abenteuerlichen" SQL-Statements schreiben :thumb:

[Sir Rufo]

Man kann mit FastReport eben beides machen:

Der quick&dirty Bericht mit direktem Zugriff auf die Datenbank
oder eben mit einem Datenpaket (wie auch immer geartet).

Der Vorteil bei so einem Datenpaket liegt eben in der Trennung von der konkreten Datenbank.

Nimmt man an der DB Änderungen vor, dann funktioniert der Report immer noch (wenn man das Datenpaket erstellen kann).
Den Report kann man auch ohne DB testen/designen (einfach ein Datenpaket unterjubeln).

[Dejan Vu]

Die Option bietet dem Kunden einfach mehr Flexibilität. Und ehrlich gesagt: Mir auch. Ich muss nämlich das Reportingmodul nicht erweitern, wenn die DB verändert bzw. erweitert wurde.

[mm1256]

Zitat:

Zitat von Dejan Vu (Beitrag 1324874)

...Ich muss nämlich das Reportingmodul nicht erweitern, wenn die DB verändert bzw. erweitert wurde.

Richtig, "müssen" musst du nicht, aber dann beinhalten deine "alten" Reports natürlich nicht die Erweiterungen der DB. Und spätestens da trennt sich meiner Meinung nach die Spreu vom Weizen bei den Report-Generatoren. Denn um Reports beim Kunden aktuell zu halten, müssen diese auch programmtechnisch (also mit einfachem Delphi-Code) erweitert werden können.

Mit L&L kann ich per DOM die alten Reports beim Kunden an die neuen Inhalte anpassen. Auch die Reports die der Kunde selber (mit dem mitgelieferten Formulardesigner) erstellt hat, deren Inhalt bzw. Aufbau/Struktur ich demzufolge gar nicht kenne. Unabhängig von der Programm-Version, d.h. ich kann ohne die Report-Version zu kennen einen beliebig alten Report auf eine aktuelle Version - mit allen Erweiterungen der DB - hochziehen. Das geht es bei jeder Änderung/Neuerung um eine Zeitersparnis in der Größenordnung von einigen hundert Stunden. :thumb:

[Dejan Vu]

Natürlich müsste ich existierende Reports anpassen, sofern die Änderung der DB auch diese betrifft.

Aber wenn ich zu dem Faktura-Modul noch eine weitere Tabellenstruktur für Vergleichsauswertungen der zwiefach genoppten Frumvondelstatistik hinzufüge, muss ich die existierenden Reports nicht anfassen. Und mein Programm muss ich auch nicht erweitern, d.h. Datenquellen hinzufügen.

Wenn der Kunde dann seine zwiefach genippften (oder waren das doch die genoppten?) Frumvondel sehen will, schicke ich ihm eine FR3-Datei und fertig ist der Lack (oder der Drops gelutscht).

Ich will mich jetzt natürlich nicht hinstellen, und behaupten, das wäre besser. Denn es kommt natürlich immer darauf an, ob ich die Kontrolle auf die Daten abgeben will bzw. ob es überhaupt Sinn macht, die Daten der DB anzuzapfen.

Das derzeitige Projekt, welches ich betreue, verfolgt genau diesen Ansatz, d.h. die Daten liegen nur in der Applikation vor und die Reportingengine bedient sich daraus. Hat Vor- und Nachteile.

[Hansa]

Normalfall dürfte wohl folgendes sein : Ich will irgendetwas nachgucken und hole mir das auf den Bildschirm. Datenmenge ist also bereits bekannt. Wenn ich das jetzt auch noch drucken will, warum soll denn dann der Report auch noch die Datenmenge neu ermitteln ?

[Dejan Vu]

Mein Normalfall ist: Kunde hat ein Reportingmodul und will eine Auswertung haben.

[mm1256]

Mein Normalfall ist: Kunde will ein Angebot oder eine Rechnung drucken. Mit Ansehen am Bildschirm alleine wird das nix :stupid:
Also vielleicht wieder zurück zum Thema "Datentrennung". Ich denke nach wie vor, je komplexer die Reports umso sinnvoller kann eine Datentrennung sein.

[Hansa]

Zitat:

Zitat von mm1256 (Beitrag 1324958)

Mit Ansehen am Bildschirm alleine wird das nix :stupid:

Na das ist ja tolle Erkenntnis. Ok, du scheinst dann ja eher irgendwas zu drucken, ohne zu sehen was. Benutzt kein Preview usw.? In diesem Fall stellt sich die Frage dann tatsächlich neu. Haentschman als Fragesteller sagt auch nichts. Tja, wozu soll man da noch etwas sagen? Wer kein PreView mag, der soll eben dafür sorgen, dass genügend blaue Tonnen vorhanden sind. 8-)

Ich bleibe aber jetzt beim Preview. Wer das so macht, der braucht für eine realistische Druckvorschau auch die entsprechenden Daten.@DejanVu,mm??? Ist das soweit klar ? Wenn ich reale Daten anzeige, dann müsseb die ja auch vorher gelesen werden ? D.h. aber dann auch, dass die Datenmenge bereits vorliegt und ich muss sie nicht erneut per Report neu lesen.

[mm1256]

Bevor jetzt die Köpfe heiß werden....bitte genau lesen was ich geschrieben habe. Es ist ja nur ein einziges "wichtiges" Wort, das du anscheinend überlesen hast: Mit Ansehen am Bildschirm alleine wird das nix. Reports ohne Druckvorschau zu drucken, habe ich also nicht behauptet. Darum verstehe ich gerade den Sinn deiner Antwort nicht.

Obwohl es aber durchaus Situationen gibt, wo eine Druckvorschau unerwünscht ist, aber das wäre ein ganz anderes Thema.

[Dejan Vu]

Zitat:

Zitat von mm1256 (Beitrag 1324958)

Also vielleicht wieder zurück zum Thema "Datentrennung". Ich denke nach wie vor, je komplexer die Reports umso sinnvoller kann eine Datentrennung sein.

Ich weiß nicht, wer vom Thema abgekommen ist.

Wie schon mehrfach wiederholt: Es kommt auf den Einsatz an. Unsere Banken verwenden Reporting Services.

[haentschman]

Moin...:P

Zitat:

Haentschman als Fragesteller sagt auch nichts

Das war ja auch keine Frage. Denn ich vertrete die Fraktion das der Report, ob als Preview oder auf Papier, ein Darstellungsknecht ist. Er kümmert sich ausschließlich nur um die Buntigkeit, die Sichtbarkeit und Ausdruck (Bildschirm, Papier) der Daten die er zur Verfügung gestellt bekommt.

Die Diskussion hat ja was gebracht. Die verschiedenen Meinungen sind für Leute die eine Entscheidung über die Implementierung treffen müssen durchaus hilfreich...:thumb:

[Dejan Vu]

Die Frage kann man ja eh nicht so pauschal beantworten, denn für den einen ist ein Report ein Darstellungsknecht und für den anderen ein komplettes Paket, welches eine Auswertung erstellen soll.

[haentschman]

Genau...8-)
Jetzt kann sich jeder, anhand der Argumente, aussuchen wie es am optimalsten zu seiner Anwendung paßt.

[Devil1925]

Gebe ich also auch mal meinen Senf dazu:

Bei uns wird ein System mit Reportstartern verwendet, bei welchem jederzeit neue Reports eingebunden werden können. Dadurch ist es schlichtweg nicht möglich für Alle Reports eine Datenquelle bereitzustellen, da über diesen einen Reportstarter X-Beliebig viele Reports gestartet werden können, welche sich auf X-Belibieg viele Datenquellen beziehen.

[Hansa]

Zitat:

Zitat von Devil1925 (Beitrag 1325065)

... bei welchem jederzeit neue Reports eingebunden werden können. Dadurch ist es schlichtweg nicht möglich für Alle Reports eine Datenquelle bereitzustellen, da über diesen einen Reportstarter X-Beliebig viele Reports gestartet werden können, welche sich auf X-Belibieg viele Datenquellen beziehen.

Sehr merkwürdig. Das soll verstehen wer will. Wie ich das Thema hier aber sehe, dann geht die Frage sowieso eher um den Einsatz datensensitiver Komponenten (Reports zähle ich da im Zusammenhang auch dazu). Tatsache ist nun, dass die logisch zwar sinnvoll wären, es kriegt aber keiner so richtig hin (egal ob Delphi oder Komponenten-Entwickler). Auch bei den (neueren) Data-Bindings scheint sich das fortzusetzen, es ist nicht wirklich richtig brauchbar. Die Programmierung dieses Krempels ist anscheinend komplizierter als gedacht. 8-) Konsequenz ist dann eben : besser nicht benutzen. Ist ja eigentlich auch nicht wichtig. Per FieldbyName etc. kann ich auch alles aus einem Dataset auslesen. Da braucht man kein DBGrid. Kaum zu glauben, aber es gibt noch eine Welt neben dem zusammenklicken und das nennt sich "programmieren".

Jetzt wieder zu den Reports : wenn jemand den Report die Datenmenge ermitteln und auch ausdrucken lässt, dann kann der das eben so machen. Er kann auch Komfort, wie Druckvorschau weglassen. Kann man noch was weglassen ? :mrgreen:

[Dejan Vu]

Bei Fastreport ist doch ein Previewer / Durckvorschau dabei? Der FR-Engine ist das doch vollkommen egal, wer die Daten bereitstell: Entweder über die Anwendung oder den in der FR-Datei selbst definierten Datenquellen... Was hat das alles nur mit nem Grid zu tun?

[Hansa]

Du weisst offensichtlich nicht, was datensensitive Komponenten sind ? Ich habe ein DBGrid angeführt und kein "Grid". Ich erkläre das dann eben mal : das DB vorne steht für Datenbank. Und es gibt da auch noch DBEdit, DBText usw. Der Unterschied zu einem "normalen" TEdit, der besteht z.B. darin, dass man eine Datenquelle angeben muss, die diese Komponenten befüllt. Dafür gibt es in Delphi die Komponente TDatasource. Rest ist mir jetzt zu blöd. :lol:

[Dejan Vu]

Mann, Datenbank? Und ich dachte, DB steht für Dumpfbacke. Wieder was gelernt.

Frohes Fest. :lol:

[Hansa]

Zuerst einmal : frohe Weihnachten an alle.

Zitat:

Zitat von haentschman (Beitrag 1325014)

Genau...8-)
Jetzt kann sich jeder, anhand der Argumente, aussuchen wie es am optimalsten zu seiner Anwendung paßt.

Aber trotz Friede, Freude, Eierkuchen muss ich da widersprechen. Hier sind leider kaum stichhaltige Argumente zu finden für oder gegen was eigentlich ?

Meine Anmerkung mit dem DBGrid wurde offensichtlich nicht verstanden (zumindest von Dejan Vu) und da kam nur "Dumpfbacke" dabei raus. Ansonsten kam aber auch nichts Neues.

Prinzipiell gibt es doch nur 3 Fälle, wie man vorgehen kann. In allen drei Fällen muss normalerweise die auszudruckende Datenmenge bestimmt werden. Also "select x,y... from blabla". Nun habe ich in meinem Dataset/Query irgendwelche Daten drin. Die drei Möglichkeiten, wie es dann weitergeht, die unterscheiden sich aber dann doch erheblich :

Fall 1 : schätze 80 % benutzen DB-sensitive Komponenten. Schnell hat man da ein sichtbares Ergebnis. Allerdings : die Flexibilität leidet stark. Im unvermeidlichen Fehlerfall ist die Suche nach der Fehlerquelle schon sehr aufwändig.

Fall 2 : Man schaufelt die Datenbank-Daten in lokale Variablen, TLabel usw. Das hätte zumindest zur Folge, dass keine Datenbankfehler mehr auftauchen können.

[TBx]

Und Fall 3?

[Hansa]

Beitrag wohl zu früh abgeschickt.

Ja, Fall 3 fehlt ja noch und das ist der wichtigste. Fest steht, dass die anzuzeigende/ zu druckende Datenmenge zuerst mal von Festplatte gelesen werden muss, egal wie.

Ich konstruiere mal ein Einsatz-Szenario : angenommen ich soll für einen neuen Mitarbeiter eine Preisliste von Art.-Nr. 1000 bis 2000 ausdrucken, die Datenmenge ist bereits da und wird auch schon in der Druckvorschau angezeigt. Nun fällt mir ein, dass eine von-bis Ausgabe nach Art.-Nr. eigentlich Blödsinnn ist, weil der Neue die Art.-Nummern noch kaum kennt. Alphabethisch wäre da wohl schon besser. Das hiesse dann : ORDER BY ändern, Datenmenge neu ermitteln und neu anzeigen usw.

Tja, Delphi hat schon mächtige Werkzeuge, die aber (leider) keiner benutzt. 99% können z.B. mit einem ClientDataSet (CDS) nichts anfangen, ausser mit dem Namen vielleicht. Darum gehts aber. Die Daten werden also wie gehabt eingelesen, landen aber dann nicht in irgendeinem DB-Zeugs, noch in vielleicht zu einfachen TLabel + Co., sondern eben direkt in einem CDS.

Wenn man das so macht, dann hat man quasi private Datenmenge. Man kommt keinem mehr in die Quere, ohne erneutes Lesen der Daten kann anders sortiert werden. Vor allem kann man aber auch datensensitive Sachen verwenden. Der Report kriegt dann nur das CDS als Datenquelle und fertig. Transaktionen, Deadlocks usw., alles uninteressant. Das läuft.

Die Vorzüge dieser Vorgehensweise muss man aber selber am Besten mal testen. Es gibt im Internet nämlich so gut wie nichts darüber zu finden. Ich kenne auch keinen, der CDS in der Praxis sinnvoll einsetzt. Doch, Stop ! Sakura macht das so ähnlich wie ich.

[Dejan Vu]

Zitat:

Zitat von Hansa (Beitrag 1325155)

Du weisst offensichtlich nicht, was datensensitive Komponenten sind ? Ich erkläre das dann eben mal : das DB vorne steht für Datenbank.

Zitat:

Zitat von Dejan Vu (Beitrag 1325165)

..Und ich dachte, DB steht für Dumpfbacke. Wieder was gelernt.:lol:

Zitat:

Zitat von Hansa (Beitrag 1325236)

Meine Anmerkung mit dem DBGrid wurde offensichtlich nicht verstanden (zumindest von Dejan Vu) und da kam nur "Dumpfbacke" dabei raus. Ansonsten kam aber auch nichts Neues.

Na ja, Hansa. Bei der Frage und der Bemerkung solltest Du keine ernstgemeinte Antwort erwarten.

Zum Thema:
Ich glaube, es ging ursprünglich mal um Reports. Was das mit CDS und lokalen Variablen zu tun hat, weiß ich jetzt nicht. Auf den vorherigen Seiten wurden zwei Sichtweisen deutlich:
1. Der Report als Darstellungsknecht von Daten.
2. Der Report als autarkes Darstellungsmodul.

Wer Kontrolle über die Daten behalten will (oder muss), wählt eher Variante 1.
Wer Flexibilität benötigt bzw. wenn die Daten aus einer Datenbank geladen werden können, wählte eher Variante 2.

[mm1256]

Zitat:

Zitat von Dejan Vu (Beitrag 1325249)

Ich glaube, es ging ursprünglich mal um Reports. Was das mit CDS und lokalen Variablen zu tun hat, weiß ich jetzt nicht. Auf den vorherigen Seiten wurden zwei Sichtweisen deutlich:
1. Der Report als Darstellungsknecht von Daten.
2. Der Report als autarkes Darstellungsmodul.

Wer Kontrolle über die Daten behalten will (oder muss), wählt eher Variante 1.
Wer Flexibilität benötigt bzw. wenn die Daten aus einer Datenbank geladen werden können, wählte eher Variante 2.

Gut zusammengefasst. Man könnte noch ergänzen:
Wer Flexibilität und Kontrolle - flexibler Schwerpunkt je nach Aufgabenstellung - benötigt, der nimmt einen Report-Knecht der Beides kann, z.B. FR oder LL.

[Dejan Vu]

Ach so, klar. Ich bin davon ausgegangen, das man eine richtige Reportengine hat.