![]() |
Datenbank: Firebird • Version: 1.5 • Zugriff über: (noch) UIB bzw. (bald) FIBPlus
DataSet vs. Query
In Version 1.0 einer adressverwaltungsartigen Software habe ich Datensätze via JvUIBQuery in ein StringGrid gelesen bzw. für INSERT, UPDATE, etc. über den gleichen Query "per Hand" in ComboBoxen oder Edit-Felder eingetragen und zurückgeschrieben....
Für Version 2.0 läuft momentan der Umbau der ganzen DB-Geschichte auf Daten-Sensitive Komponenten mittels Anbindung an DataSource / DataSet.... Soweit so gut, hab nun aber letztens in irgendeinem Post gelesen (Sorry, find den net mehr), dass man sich bei größeren Anwendungen mit der Verwendung von DataSets und DB-Sensitiven Kompos die Karten legt???? Ist das wirklich so??? Und wenn ja, wie realisiert man "größere" Projekte dann??? Welchen Sinn machen die DataSet etc. dann überhaupt? |
Re: DataSet vs. Query
Ich weiss nicht genau, was "sich die Karten legen" bedeuten soll. Aber in unseren wirklich größeren Projekten kommen wir um Datasets nicht herum. Wir haben zig DB-Komponenten, die hängen nunmal an einer Datasource und damit an Datasets. Also echt kein Problem, es sei denn die Komponenten haben einen Hau weg. Aber da kann Delphi nix für ;)
Sherlock |
Re: DataSet vs. Query
Ein Query ist auch eine DataSet, da davon abgeleitet.
Zitat:
Zitat:
Zitat:
|
Re: DataSet vs. Query
Zitat:
Zitat:
Zitat:
|
Re: DataSet vs. Query
Zitat:
Wir bauen auf Oracle, die DOAS und InfoPower, es schnurrt wie ein Kätzchen. Dieses ganze Multilayer getue ist doch wirklich unnötig. Es ist nichtmal nötig einen Oracle Client auf den Clients zu installieren, die DOAs verbinden sich direkt mit der DB. Sherlock |
Re: DataSet vs. Query
Bernhard meint auch was anderes. Er redet von einer echten objektorientierten Arbeitsweise, mit Klassen, welche Manipulationen direkt in Änderungen automatisch auf Datenbankebene abbilden. Mit welchen Komponenten/Bibliotheken usw. der Zugriff auf unteren Schichten auf das DBMS erfolgt ist dann eine andere Sache.
|
Re: DataSet vs. Query
Zitat:
Zitat:
|
Re: DataSet vs. Query
Ich muss auch sagen, das man mit DB-sensitiven Elementen zu unflexibel ist. alleine schon das Speichern via ADO ist ein Krampf, wenn man sich das von ADO generierte SQL-Statement anschaut. Leider ist da nix dran zu drehen. Mit den von Bernhard angesprochenen Layern ist man einfach flexibler, kann den Code wiederverwenden und hat bei einer Umstellung auf N-Tier-Architektur auch die besseren Karten.
Der einzige Vorteil von DB-sensitiven Elementen (neben den von Bernhard genannten), insbesondere Datagrids, ist, das man zur Designzeit alles hübsch machen kann. Aber das war's dann auch. Wir verwenden manchmal Mem-Datasets, in die wir die Daten von der DB reinkopieren. Dann haben wir einerseits DB-Elemente und andererseits die Abstraktion zwischen GUI und Speicherung. Da wir sehr viel mit Grids arbeiten und da eben mit der Visualisierung komplexer Daten, ist das schon besser so. |
Re: DataSet vs. Query
Zitat:
Was die Clients betrifft, ist das natürlich korrekt, aber nicht unbedingt immer. Manche Software die sonst noch bei den Kunden läuft setzt auch auf Oracle, aber setzt andere Clientversionen voraus, da ist es praktisch, wenn man die Ora-Clients umgehen kann. Sherlock |
Re: DataSet vs. Query
Zitat:
Zitat:
Aber werden wir jetzt nicht sehr Off-Topic :gruebel: |
Alle Zeitangaben in WEZ +1. Es ist jetzt 17:29 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz