[Tutorial] Laden / Speichern von Objekten in einer normalisierten Datenbank

[Rollo62]

Wieso nur gnädig, ich bin doch immer froh wenn sich einer die Zeit nimmt etwas genauer zu erklären

Ich frage mich bei dem ganzen ORM nur immer ob es der richtige Weg ist.
Datenbanken wurde noch gemacht um 1 bis 1Mio. Datensätze zu verwalten.
ORM mit Listen im Speicher (OK, ich lass man das intelligente Speicherverwalten weg),
das läuft doch bei 1 Mio. Datensätze in eine Krise.

Dann die Anbindung der Daten an die Controls.
Im Prinzip bin ich ja voll dafür, also heist die Richtung LiveBinding,
nur leider funktioniert das nur rudimentär.
Welches Konzept hast du denn dafür, etwas Eigenes drüberstülpen ?

Rollo

[Jumpy]

Zitat von Rollo62:

Ich frage mich bei dem ganzen ORM nur immer ob es der richtige Weg ist.
Datenbanken wurde noch gemacht um 1 bis 1Mio. Datensätze zu verwalten.
ORM mit Listen im Speicher (OK, ich lass man das intelligente Speicherverwalten weg),
das läuft doch bei 1 Mio. Datensätze in eine Krise.

Ob du nun die 1 Mio. Datensätze in Listen mit Objekten oder aber in einem Dataset hast, wenn du dir 1 Mio. Datensätze von der DB holst, hast du die halt im Speicher. Aufpassen was du dir an Datensätzen holst must du immer selber, egal ob mit oder ohne ORM.

[haentschman]

Hallöle...

Zitat:

Ich frage mich bei dem ganzen ORM nur immer ob es der richtige Weg ist.

...für mich gibt es keinen Anderen. Ich bin durch die Einschränkungen der datensensitiven Controls, der Datasets, und vor Allem dem Durcheinander mit den Querys auf den Forms dazu gekommen. Im früherem Leben habe ich auch die Queries auf der Form mit DB Controls gehabt. Mit steigenden Anforderungen war das mir einfach zu unübersichtlich. Deshalb habe ich nach einer anderen Möglichkeit gesucht und gefunden...

Zitat:

ORM mit Listen im Speicher (OK, ich lass man das intelligente Speicherverwalten weg), das läuft doch bei 1 Mio. Datensätze in eine Krise.

...wie schon Jumpy sagte:

Zitat:

Ob du nun die 1 Mio. Datensätze in Listen mit Objekten oder aber in einem Dataset hast, wenn du dir 1 Mio. Datensätze von der DB holst, hast du die halt im Speicher. Aufpassen was du dir an Datensätzen holst must du immer selber, egal ob mit oder ohne ORM.

...du mußt selbst entscheiden welche Datensätze zu holst. Der Rest liegt im Datengrab...

Zitat:

Dann die Anbindung der Daten an die Controls.

...wo ist das Problem? Manches muß man auch manuell machen. Dafür heißt es auch programmieren...

Zitat:

Im Prinzip bin ich ja voll dafür, also heist die Richtung LiveBinding, nur leider funktioniert das nur rudimentär.

Livebindings habe ich probiert. Overhead war mir deutlich zu groß. Dann lieber klassisch. http://www.delphipraxis.net/190711-l...ceadapter.html

Zitat:

Welches Konzept hast du denn dafür, etwas Eigenes drüberstülpen ?

...weniger Probleme.

[Rollo62]

Ich binn dann wohl immer noch im Irrglauben das die Datasets nicht Alle Daten im Speicher halten, sondern nur intelligent per Chinks sich die passenden Häppchen holen.

Das hängt sicher vom Query ab, ein FDMemTable oder ClientDataSet hat Alles im Speicher,
aber was ist mit TFDQuery, oder ähnlichen Konstrukten ?

Die sollen das doch genau das Daten- und MemoryManagement vor mir Kapseln.

ORM ist gut und richtig, das sehe ich auch so.
Aber warum eigentlich nicht direkt von TDataset auf die Controls binden ?
Warum unbedings Objekte dazwischenbauen ?
(Ok, ich verstehe das man in den Objekten tolle Logik reinbauen kann, aber sollte man das wirklich dort machen) ?

Mit einer Wrapperklasse sollte das doch "einfach" möglichs ein.
TDbGrid macht das doch im Prinzip auch so, nur der der Wrapper im DBGrid selber ist, sozusagen.

LiveBinding per Code macht das im Prinzip so, mit FillExpressions z.B. für ListView,
und da glaube ich eben auch das dies der richtige Weg ist, das per RTTI zu entkoppeln.

So in dieser Richtung, am liebsten per Code:

Delphi-Quellcode:

   FDb.Bind(Query1, ListView, 'Name',  'Text')
      .Bind(Query1, ListView, 'Descr', 'Detail')
      .Bind(Query1, ListView, 'ImgId', 'ImageIndex')
      .Bind(Query1, Grid1,    '*')
      .Bind(Query1, Edit1,    'Name',  'Text',  dbBidirectional)
      ...
      ;

Rollo

[Uwe Raabe]

Zitat von Rollo62:

Ich binn dann wohl immer noch im Irrglauben das die Datasets nicht Alle Daten im Speicher halten, sondern nur intelligent per Chinks sich die passenden Häppchen holen.

Das hängt sicher vom Query ab, ein FDMemTable oder ClientDataSet hat Alles im Speicher,
aber was ist mit TFDQuery, oder ähnlichen Konstrukten ?

TFDQuery holt sich zwar die Daten häppchenweise, behält diese aber im Speicher - außer, es ist Unidirectional aktiv, dann werden die bereits besuchten Datensätze wieder aus dem Speicher geworfen.

Bezüglich ORM und DataSet/DBControls: Bei TMS Aurelius gibt es extra ein TAureliusDataset um die beiden Welten wieder zu vereinen.

[haentschman]

Zitat:

Aber warum eigentlich nicht direkt von TDataset auf die Controls binden ?

1. u.a. Faulheit. Ich habe die Faxen von ständig Query.FieldByName('FBlubb').AsInteger voll.
2. Weil ich die Daten im DataSet nicht strukturieren kann. Ähnlich einer Ordnerstruktur.

Zitat:

Warum unbedings Objekte dazwischenbauen ?

1. Im Quelltext steht kein einziger Feldname.
2. Die Datenbank oder die Datenquelle ist komplett getrennt. Die Daten können über das Interface aus Oma´s Küchenschrank kommen. Der Küchenschrank kennt kein DataSet sondern XML...
3. Das macht das Wechseln zwischen den Datenbanken / Quellen einfacher. Getrennte Statements je Interface für die verschieden DBMS.
4. Am Breakpoint kann man sich das komplette Objekt mit seinen Daten ansehen.

eine Bitte:

Zitat:

Bei TMS Aurelius gibt es

...das wir in diesem Tutorial nur über dieses Beispiel ORM diskutieren. Danke.

[Rollo62]

Wenn ich das richtig sehe hast du keine Interaktion drin, die Controls werden gefüllt.
Der Spass fängt aber dann an wenn du ein Grid oder Listview scrollen und editieren möchtest,
wenn Master-Detail sich synchronisieren müssen, korrekt die Daten in die DB zurückschreiben, etc..
Das müsste ja meiner Meinung nach auch gekapselt werden, das will man nicht immer wieder neu schreiben müssen.
Ich sehe das so das es eine Art "Bindings" in irgendeiner Form geben müsste, zum einen für die Daten (so wie du es hast z.B.), zum anderen eben diese Events (abhängig vom jeweiligen Control
und "Style" der Bedienung).

Wie würdest du denn so etwas bei deinem Vorschlag lösen ?

Rollo