Pro/Contra Virtuelle Tabelle oder TObjectList

[norwegen60]

Hallo zusammen,

mich würde interessieren, ob es entscheidende Vor-/Nachteile zwischen einer virtuellen Tabelle (z.B. TJvMemoryData) oder TObjectList gibt.

Auf die virtuellen Tabellen bin ich gestoßen, weil ich die Daten der aktuelle bestehenden TObjectList(en) in QuickReport ausgeben muss. Der einfachste Weg schien mir, die TObjectList in eine TJvMemoryData zu speichern. Die wird dann von den TSubDetail-Bändern genau gleich behandelt wie die normalen Datenbank-Tabellen.

Warum ich überhaupt TObjectList verwende?
Weil die Datenstruktur der gegebenen Datenbank grauenhaft ist und ein Umstellung ist aufgrund Datenintegrität nahezu unmöglich. Von daher haben wir ein Klassenbaum aufgebaut, der die Daten verwaltet. Nur beim Einlesen und der Ausgabe müssen wir uns mit der DB beschäftigen. Hat auch den Vorteil, dass wir von der DB unabhängig sind wenn die Daten mal eingelsen sind. Ein Test läuft also auch dann weiter, wenn sich die DB mal abhängt.

Bisher habe ich nie virtuelle Tabellen eingesetzt. Deshalb die Frage, welche Probleme zu erwarten sind. Oder gibt es bessere Alternativen als TJvMemoryData.

In einem neueren Projekt könnte ich auch auf TUniDac zurückgreifen. Das wird in diesem Projekt aber nicht eingesetzt. Falls deren TVirtualTable aber erheblich Vorteile bietet, könnte man darüber nachdenken, UniDac zu verwenden.

Was mich ein bisschen stört, ist dass die Daten jetzt zweifach vorhanden sind. Immer in der TObjectList und beim Drucken auch noch in JvMemoryData.

Das ganze Projekt ist noch Delphi XE

Grüße und Danke für Feedbacks

Gerd

[Stevie]

Gibt mMn kein entweder oder - sowas wie TJvMemoryData o.ä kann genutzt werden, um bereits in anderer Form vorhandene Daten von Dingen zu konsumieren, die mit TDataSet arbeiten - z.B. Grids.

Falls die Daten sowieso direkt aus der Datenbank kommen, und dafür erst Objekte gebaut werden, die dann in eine Liste gepackt werden, die dann über ein TJvMemoryData an einen Report gegeben werden, ist das möglicherweise durchaus ungünstig und es wäre besser, die Daten direkt in einem Dataset aus der Datenbank zu saugen und an den Report zu geben.

TL'DR: Es kommt drauf an

[himitsu]

Also ich lese überall immer raus
* ORM und wildes Databinding mit vielen gutklingenden Zwischenschichten ist cool
* und DataSets sind sowas von vor 80 Jahren

Zitat:

Falls die Daten sowieso ...

Das wäre ja viel zu einfach und nicht modern genug,
nja, warum einfach und direkt, wenn man auch viele Umwege machen kann.

[bcvs]

Die Daten sind aber anscheinend eh schon in TObjectListen. Da würde ich den QuickReport direkt aus der TObjectList füttern, gesteuert über den OnNeedData - Event.

[norwegen60]

Wie schon gesagt, sprechen zwei Gründe gegen die direkte Anbindung per Datasets

• Die Datenstruktur ist dazu völlig ungeeignet. Weiter möchte ich darauf nicht eingehen, denn das ist leider gegeben
• Durch das einlesen in eien Klassenstruktur kann die DB auch mal Offline sein ohne dass die Anwendung bockt.

Der Ansatz über OnNeedData ist interessant, erscheint mir auf die Schnelle aber aufwändiger, als das einlesen der Daten in eine virtuelle Tabelle. Die kann ich dann sowohl für die Ausgabe in ein Grid, in einen Chart oder in QuickRep verwenden. Mit der VirtualTable kann ich dann einfach im Object-Inspector den TQRDBText-Feldern die Tabellen-Felder zuweisen.
OnNeedData benötigt wohl so was in der Art:

Delphi-Quellcode:

  QrLabel1.Text := IntToStr(Liste[i].Nr);
  QrLabel2.Text := Liste[i].Name;
  QrLabel3.Text := Format('%5.3f',[Liste[i].Wert]);

Das ist dann doch mehr Aufwand wenn man das mal für QuickReport, mal für ein Grid und das näcshte mal für ein Chart macht.
Oder übersehe ich was.

Was klar dagegen spricht ist die Mehrfachhaltung der Daten.

Im Grunde ging es mir auch eher darum, ob es bei VirtualTables Besonderheiten gibt die zu beachten wären, bzw. ob es generelle Vor-/Nachteile gibt.

[himitsu]

Zitat:

Die kann ich dann sowohl für die Ausgabe in ein Grid, in einen Chart oder

Wenn du mal in Richtung Firemonkey guckst, dann ist TList, Array oder DataSet kein großer Unterschied, da du alles erst über einen Adapter an die Oberfläche databindest.
(k.A. wie ob/wie QuickReport dort arbeitet)

Im Prinzip kann man auch für TDataSet einen Adapter schreiben, egal ob FMX oder VCL, wo ein DataSet intern auf die Daten einer (Objekt)Liste zugreift, anstatt auf ein DBMS.

[freimatz]

Zitat von himitsu:

ORM und wildes Databinding mit vielen gutklingenden Zwischenschichten ist cool

nope. ORM und durchdachtes Databinding mit ausreichend Zwischenschichten ist cool

Warum eigentlich konkret TJvMemoryData? Es gibt doch noch etliche andere Memory Datasets.

Und wenn schon TObjectList, dann TObjectList <>
Meine 42 cents