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 von Moebius97:

...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 von Moebius97:

... 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 von Moebius97:

....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 von exilant:

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 ? Z.B. das : 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 ? ). 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.

[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 von nachti1505:

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

Das ist zumindest keine Vererbungs-Kette, wie von mir beschrieben. Siehe hier : 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 von mkinzler:

Zudem ist die Richtung falsch.

Kommt aber auch drauf an, in welcher Richtung man liest. 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