Datenbank: Firebird • Version: 2.5 • Zugriff über: Interbase Express
DataSet und die Datenbanklogik
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? |
AW: DataSet und die Datenbanklogik
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? |
AW: DataSet und die Datenbanklogik
Zitat:
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:
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. |
AW: DataSet und die Datenbanklogik
Zitat:
Zusammengefasst: verwende nicht TDataset, verwende keine datengebundenen Komponenten, verwende Zugriffskomponenten die aktuelle Firebird Versionen unterstützen, beherzige das MVC Modell. |
AW: DataSet und die Datenbanklogik
Im grossen und ganzen stimmt das so schon. Nur was soll das :
Zitat:
Delphi-Quellcode:
Welche Alternative gibt es denn dazu ? Und wo kommt das her ? Richtig von TDataset bzw. bei Delphi 10+ von TWideDataset.
TpFIBDataSet
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: |
AW: DataSet und die Datenbanklogik
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!
|
AW: DataSet und die Datenbanklogik
Zitat:
Delphi-Quellcode:
Das sind lediglich Properties, die zugewiesen werden können und sonst nichts. Vererbt wird da nichts.
TDataSource = class(TComponent)
|
AW: DataSet und die Datenbanklogik
Zudem ist die Richtung falsch.
|
AW: DataSet und die Datenbanklogik
Zitat:
|
AW: DataSet und die Datenbanklogik
Das Grid weist aber auf die DataSource und diese auf das DataSet
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 13:34 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