AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Reports allgemein Datentrennung

Ein Thema von haentschman · begonnen am 18. Dez 2015 · letzter Beitrag vom 25. Dez 2015
Antwort Antwort
Seite 1 von 3  1 23   
Benutzerbild von haentschman
haentschman

Registriert seit: 24. Okt 2006
Ort: Seifhennersdorf / Sachsen
5.275 Beiträge
 
Delphi 12 Athens
 
#1

Reports allgemein Datentrennung

  Alt 18. Dez 2015, 09:41
Hallöle...
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. 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. Der Report hat von mir aus als "Schnittstelle" Datasets. Wie und woher die gefüllt werden ist dem Report doch wurscht... Der Report bekommt Daten und macht ein Bild daraus. Für etwas anderes ist er nicht da...

Fröhliches diskutieren...
  Mit Zitat antworten Zitat
Bambini
(Gast)

n/a Beiträge
 
#2

AW: Reports allgemein Datentrennung

  Alt 18. Dez 2015, 09:50
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
Eine super Sache, ich geben via Scripting sogar den Zugriff auf das Objekt-Model.
  Mit Zitat antworten Zitat
Der schöne Günther

Registriert seit: 6. Mär 2013
6.093 Beiträge
 
Delphi 10 Seattle Enterprise
 
#3

AW: Reports allgemein Datentrennung

  Alt 18. Dez 2015, 09:56
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.
  Mit Zitat antworten Zitat
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
6.659 Beiträge
 
FreePascal / Lazarus
 
#4

AW: Reports allgemein Datentrennung

  Alt 18. Dez 2015, 12:12
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
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector

Geändert von p80286 (18. Dez 2015 um 12:15 Uhr)
  Mit Zitat antworten Zitat
mm1256

Registriert seit: 10. Feb 2014
Ort: Wackersdorf, Bayern
640 Beiträge
 
Delphi 10.1 Berlin Professional
 
#5

AW: Reports allgemein Datentrennung

  Alt 18. Dez 2015, 13:15
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
Gruss Otto
Wenn du mit Gott reden willst, dann bete.
Wenn du ihn treffen willst, schreib bei Tempo 220 eine SMS
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#6

AW: Reports allgemein Datentrennung

  Alt 18. Dez 2015, 18:25
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).
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#7

AW: Reports allgemein Datentrennung

  Alt 19. Dez 2015, 08:48
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.
  Mit Zitat antworten Zitat
mm1256

Registriert seit: 10. Feb 2014
Ort: Wackersdorf, Bayern
640 Beiträge
 
Delphi 10.1 Berlin Professional
 
#8

AW: Reports allgemein Datentrennung

  Alt 19. Dez 2015, 14:34
...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.
Gruss Otto
Wenn du mit Gott reden willst, dann bete.
Wenn du ihn treffen willst, schreib bei Tempo 220 eine SMS
  Mit Zitat antworten Zitat
Dejan Vu
(Gast)

n/a Beiträge
 
#9

AW: Reports allgemein Datentrennung

  Alt 19. Dez 2015, 17:14
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.
  Mit Zitat antworten Zitat
Hansa

Registriert seit: 9. Jun 2002
Ort: Saarland
7.554 Beiträge
 
Delphi 8 Professional
 
#10

AW: Reports allgemein Datentrennung

  Alt 20. Dez 2015, 12:11
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 ?
Gruß
Hansa
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 3  1 23   

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:21 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz