DataSet und die Datenbanklogik

[Moebius97]

Hallo allerseits,
wir hatten öfter schon das Thema, dass man an generierte IDs (AutoInc usw.) nicht ohne Weiteres in seiner Delphi-anwendung heran kommt, wenn neue Datensätze angelegt werden. Nachdem ich die entsprechenden Krücken eingebaut habe (eigene Abfrage eines Generators und dessen ID verwenden), wird mir jetzt eine Feldberechnung zu früh ausgeführt. Es handelt sich um ein per Firebird mit "computed by"-Ausdruck berechnetes Zeitstempelfeld. Ich hätte gerne ein Paar aus Komponenten und Datenbank, das mir solche Hacks erspart. Ich möchte die Datenbanklogik soweit wie möglich in die Datenbank verlagern und Komponenten, die das auch berücksichtigen.

Hintergrund: Es geht um ein Datenmodul, auf dem mehrere TIBTable-Komponenten kleben. Ich hänge in der "Haupttabelle" AfterInsert- und Afterscroll-Handler ein. In AfterInsert muss ein Datensatz in einer abhängigen Tabelle angelegt werden, der ein berechnetes Feld enthält (das für die Anzeige erstmal nicht gebraucht wird). Dort knallt es "0.0 ist kein gültiger Zeitstempel". AutoCalcfields abzuschalten, nützt übrigens nichts.

Hat jemand eine Empfehlung für ein "sauberes System"? Kann ich mit stabileren Komponenten auf eine Firebird-DB zugreifen? Oder sollte ich die DB doch wechseln?

[Blup]

Das hört sich für mich erst mal nach ungüstiger Datenbank- und Anwendungsstruktur an.
Mit anderen Datenbanksystemen würden vermutlich ähnliche Probleme auftauchen.
Zeig uns doch mal die Struktur und die Abhängigkeiten beider Tabellen.
Tritt der Fehler beim Post in der Haupttabelle auf, weil dort ein Feld noch nicht belegt ist?

[sx2008]

Zitat:

Zitat von Moebius97 (Beitrag 1059088)

...Nachdem ich die entsprechenden Krücken eingebaut habe (eigene Abfrage eines Generators und dessen ID verwenden)

Also du kannst froh sein, eine Datenbank zu benützen, die Generatoren kennt.
In anderen DBMS müsstest du den Generator künstlich nachbilden.
Einen Generator zu verwenden ist keine Krücke, sondern eigentlich sind AUTOINC-Felder die Krücke.
AUTOINC-Felder wiegen den Programmierer in der falschen Sicherheit, er müsse sich nicht um die Primärschlüsselfelder kümmern.
Sobald man aber abhängige Tabellen hat, entsteht das Problem, dass man den Wert des Feldes nicht kennt.

Zitat:

Zitat von Moebius97 (Beitrag 1059088)

... Es handelt sich um ein per Firebird mit "computed by"-Ausdruck berechnetes Zeitstempelfeld. ... Ich möchte die Datenbanklogik soweit wie möglich in die Datenbank verlagern und Komponenten, die das auch berücksichtigen.

Es gibt 3 Haupt-Gründe weshalb man Logik in die Datenbank verlagert:
1.) Geschwindigkeit. Manche Dinge werden auf der Datenbank wesentlich schneller ausgeführt als über die Anwendung
2.) Mehrere verschiedene Anwendungen greifen auf die gleiche Datenbank zu
Durch Verlagerung von Logik in die Datenbank vermeidet man das Implementieren der Logik in mehreren Anwendungen.
Falls unbekannte neue Anwendungen auf die Datenbank zugreifen profitieren diese automatisch
3.) Schutz der Datenbank vor inkonsistenten Daten; Erzwingung von Integritätsregeln

Ich vermute mal, dass in deinem Fall keiner der Gründe zutrifft und dass du nur deshalb das "computed by"-Feld verwendest um deine Anwendung etwas zu vereinfachen.
Man müsste jetzt die genaue Tabellenstruktur und das gewünschte Ergebnis kennen, aber mit einer SQL-Query oder einem CalculatedField (lokal im Dataset berechnet) kommst du auch ans Ziel.

[exilant]

Zitat:

Zitat von Moebius97 (Beitrag 1059088)

....Hat jemand eine Empfehlung für ein "sauberes System"? Kann ich mit stabileren Komponenten auf eine Firebird-DB zugreifen? Oder sollte ich die DB doch wechseln?

Vergiss Tdataset und seine hässlichen (TTable-) Kinder. Das ganze Dataset Geraffel führt nur zu einer üblen Verquickung von Anwendungslogik und GUI Programmierung. Firebird unterstützt INSERT/RETURNING. Mit den ZEOS oder (noch besser FIBPLUS) Komponenten kommst Du problemlos an die im Trigger vergebenen Generator Werte. Die DB musst Du dazu sicher nicht wechseln.
Zusammengefasst: verwende nicht TDataset, verwende keine datengebundenen Komponenten, verwende Zugriffskomponenten die aktuelle Firebird Versionen unterstützen, beherzige das MVC Modell.

[Hansa]

Im grossen und ganzen stimmt das so schon. Nur was soll das :

Zitat:

Zitat von exilant (Beitrag 1059104)

Vergiss Tdataset und seine hässlichen (TTable-) Kinder.

Die TTable-Kinder soll er wirklich vergessen, aber was hat das mit TDataSet zu tun ? Das ist die gemeinsame Grundlage. Bei TTable siehts jetzt so aus : erben tut das von TDBDataSet, das von TBDEDataset und letztendlich von TDataset. Das TDataSet kann man sowieso nicht einfach so benutzen, sondern nur die entsprechenden Ableitungen. Was soll man denn überhaupt benutzen, wenn nicht von TDataSet abgeleitete Komponenten ? :shock: Z.B. das :

Delphi-Quellcode:

TpFIBDataSet

Welche Alternative gibt es denn dazu ? Und wo kommt das her ? Richtig von TDataset bzw. bei Delphi 10+ von TWideDataset.

Das TDataSet ist deshalb so wichtig, um die Kompatibilität zu wahren. Wer sich nicht mal daran hält, der wird auf mittlere Sicht Schiffbruch erleiden. Siehe IBObjects. Lange nichts mehr davon gehört (Zeos nicht auch ? :gruebel:). Aber im Endeffekt trotzdem logisch. Die TdataSet-Inkompatibilität hat dafür gesorgt, dass es sehr sehr viel Arbeit gibt. Mir wärs auch zu blöd das Rad jedesmal neu zu erfinden (z.B. TMyDbGrid + Co.) und noch an jede neue Delphi-Version anzupassen. :mrgreen:

[nachti1505]

Für Anfänger besteht hier aber ganz schnell die Gefahr (wie oben beschrieben), dass durch die Kette TDataset->TDataSource->TDBGrid ganz schnell MVC verlassen wird. Und das später wieder gerade zu biegen... na ja, ich weiß was das bringen kann!

[Hansa]

Zitat:

Zitat von nachti1505 (Beitrag 1059115)

dass durch die Kette TDataset->TDataSource->TDBGrid ganz schnell...

Das ist zumindest keine Vererbungs-Kette, wie von mir beschrieben. Siehe hier :

Delphi-Quellcode:

TDataSource = class(TComponent)

Das sind lediglich Properties, die zugewiesen werden können und sonst nichts. Vererbt wird da nichts.

[mkinzler]

Zudem ist die Richtung falsch.

[Hansa]

Zitat:

Zitat von mkinzler (Beitrag 1059119)

Zudem ist die Richtung falsch.

Kommt aber auch drauf an, in welcher Richtung man liest. :mrgreen: Habe mir allerdings nochmals die Ausgangsfrage durchgelesen. Da werden TIBTables benutzt ? Wieso steht dann im Titel was von DataSet ? Wie bereits gesagt : das ist ein nicht zu unterschätzender Knackpunkt. Dann noch zu den Events und IBX, rückgelieferter ID usw.: habe da ein ungutes Gefühl. Zumindest letzteres war definitiv zur Zeit des Auseinanderlaufens von Interbase und Firebird noch nicht da. Ob das mit den Interbase (also IBX)-Komponenten richtig geht ? Ich wäre sehr sehr vorsichtig mit allem, was im Zusammenhang mit Firebird, in Interbase 6.0 noch nicht ging !!

[mkinzler]

Das Grid weist aber auf die DataSource und diese auf das DataSet

[exilant]

Zitat:

Zitat von Hansa (Beitrag 1059113)

[...] Das TDataSet ist deshalb so wichtig, um die Kompatibilität zu wahren. Wer sich nicht mal daran hält, der wird auf mittlere Sicht Schiffbruch erleiden. Siehe IBObjects. Lange nichts mehr davon gehört (Zeos nicht auch ? :gruebel:). Aber im Endeffekt trotzdem logisch. Die TdataSet-Inkompatibilität hat dafür gesorgt, dass es sehr sehr viel Arbeit gibt. Mir wärs auch zu blöd das Rad jedesmal neu zu erfinden (z.B. TMyDbGrid + Co.) und noch an jede neue Delphi-Version anzupassen. :mrgreen:

Man braucht TDataset nicht um "die Kompatibilität zu wahren". Man braucht TDataset schlicht garnicht.
Die ganzen TDB* Komponenten sind böse. Sie lösen wie schon gesagt das MVC auf. "Good practice" ist es, Daten mittels eines leichtgewichtigen Querys (unidirektional, nicht "lebendig", dafür aber schnell) in geeignete Datenstrukturen (Klassen, Listen von Klassen) einzulesen und via UPDATE und INSERT Statements entsprechender Methoden zu aktualisieren. Damit werden Abhängigkeiten vom DBMS, von GUI Komponenten und im weitesten Sinne sogar von der Programmierumgebung verhindert. Genau die Falle die Du oben beschreibst wird vermieden. Mr. Whartons IBObjects Problem war, nicht erkannt zu haben das Datasets ein Irrweg sind. IBObjects wollte wie die BDE sein, nur "besser".
Die Anzeige der Daten ist eine andere Baustelle. Statt TDb* benutzt man nicht-datengebundene Controls zur Visualisierung/Editierung. Das bringt flexibilität und Geschwindigkeit. Das rumhantieren auf "Tables" bzw. "Live Querys" ist eine Unart der ich zu Clipper/dBase Zeiten auch mal gefrönt habe. Und meine ersten Delphi/BDE Anwendungen sahen auch so aus. Aber die Zeit ist nicht stehen geblieben. Die 80er und 90er sind vorbei. Spätestens beim Einsatz fortgeschrittener Techniken wie ORMs kann man Datasets eh' vergessen. Ich kann wirklich nur jedem raten, sich von TDatsets fernzuhalten.

[nachti1505]

Zitat:

Zitat von mkinzler (Beitrag 1059119)

Zudem ist die Richtung falsch.

TDataset->TDataSource->TDBGrid

Aus der Nutzung von TDataset folgt, der Entwickler setzt noch ein TDataSource auf das Formular und aus der Nutzung der TDataSource folgt, der Entwickler nutzt ebenfalls das (bspw.) TDBGrid! Und schon hat man alles auf einem Forumlar, ganz entgegen dem MVC?

Ich wollte damit nur ausdrücken, dass meine Projekte eine zeitlang gelitten haben, nachdem ich das TDataSet (bzw. deren Nachfahren) entdeckte! Eben wegen oben genannter Kausalkette...

[ot]
Wie würdet ihre denn den Operator "aus x folgt y" darstellen, wenn nicht so "-->"?
[/ot]

[Moebius97]

Hallo nochmal,
ich unhöflicher Mensch! Ich wollte hier nur nochmal
1. mich für die Antworten bedanken.
2. Dadurch fühlte ich mich darin bestärkt, Abstand von den Daten gebundenen Komponenten zu nehmen und die Mehrarbeit zu investieren. Erste Versionen laufen, und es sieht so aus, als könnte ich damit weiter entwickeln.
Veilen Dank und schöne Grüße,

Mario