DataSet vs. Query

[nachti1505]

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?

[Sherlock]

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

[mkinzler]

Ein Query ist auch eine DataSet, da davon abgeleitet.

Zitat:

Ist das wirklich so???

Kommt darauf an, man ist halt der vorgegeben Logik/Abläufen innerhalb des Datenteils der VCL ausgeliefert. Wenn du bessere Kontrolle willst, solltest du darauf verzichten.

Zitat:

Und wenn ja, wie realisiert man "größere" Projekte dann???

Z.B. so wie du es bei v.1 machst.Ist aber eine Geschmackssache. man kann auch größere Projekte mit data-aware Komponenten realisieren.

Zitat:

Welchen Sinn machen die DataSet etc. dann überhaupt?

Wie schon oben geschrieben brauchst du ja nicht auf DataSets zu verzichten, die Frage ist eher ob mal datensensitive Kompos verwenden sollte.

[Bernhard Geyer]

Zitat von nachti1505:

Für Version 2.0 läuft momentan der Umbau der ganzen DB-Geschichte auf Daten-Sensitive Komponenten mittels Anbindung an DataSource / DataSet....

Stop Stop! Mach es nicht. DB-Sensitive Controls sind für komplexere Anwendungen zu unflexibel. Wird haben lange genug benötigt um noch die letzten reste DB-Sensitive Controls aus einer großen Anwendung (1 Mio. Quellzeilen) zu entfernen und damit die letzten damit verbundenen Performancebremsen zu beseitigen.

Zitat von nachti1505:

Und wenn ja, wie realisiert man "größere" Projekte dann???

Objektorientiert mit einem eigenen DB-Access-Layer welche die umwandlung Relationales Speichern <-> Objektmodell durchführt.

Zitat von nachti1505:

Welchen Sinn machen die DataSet etc. dann überhaupt?

Für kleinere Anwendungen, Prototypen oder Demos sind DB-Sensitive Controls 1a zu verwenden.

[Sherlock]

Zitat von Bernhard Geyer:

Zitat von nachti1505:

Und wenn ja, wie realisiert man "größere" Projekte dann???

Objektorientiert mit einem eigenen DB-Access-Layer welche die umwandlung Relationales Speichern <-> Objektmodell durchführt.

Wieso das denn?

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

[mkinzler]

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.

[Bernhard Geyer]

Zitat von Sherlock:

Wir bauen auf Oracle, die DOAS und InfoPower, es schnurrt wie ein Kätzchen. Dieses ganze Multilayer getue ist doch wirklich unnötig.

Und wenn ein großer Auftrag Winkt bei denen ihre nicht Oracle einsetzen könnt würdet ihr froh sein alles was speziell für eine DB ist nicht in allen Units verstreut zu haben. Wir können sagen: Da, diese 3 DBMS darfst du verwenden und nimm das was dir am liebsten ist.

Zitat von Sherlock:

Es ist nichtmal nötig einen Oracle Client auf den Clients zu installieren, die DOAs verbinden sich direkt mit der DB.

Die Kunden die Oracle nehmen ist das egal. Da ist eh schon auf allen Rechnern der Client installiert.

[alzaimar]

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.

[Sherlock]

Zitat von Bernhard Geyer:

Zitat von Sherlock:

Wir bauen auf Oracle, die DOAS und InfoPower, es schnurrt wie ein Kätzchen. Dieses ganze Multilayer getue ist doch wirklich unnötig.

Und wenn ein großer Auftrag Winkt bei denen ihre nicht Oracle einsetzen könnt würdet ihr froh sein alles was speziell für eine DB ist nicht in allen Units verstreut zu haben. Wir können sagen: Da, diese 3 DBMS darfst du verwenden und nimm das was dir am liebsten ist.

Zitat von Sherlock:

Es ist nichtmal nötig einen Oracle Client auf den Clients zu installieren, die DOAs verbinden sich direkt mit der DB.

Die Kunden die Oracle nehmen ist das egal. Da ist eh schon auf allen Rechnern der Client installiert.

Wir produzieren Standardsoftware, da gibts keine Auftragsarbeit... bzw. wenn dann nur unter unseren Bedingungen.

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

[Bernhard Geyer]

Zitat von Sherlock:

Wir produzieren Standardsoftware, da gibts keine Auftragsarbeit... bzw. wenn dann nur unter unseren Bedingungen.

Wir auch. Und wir hätten mit Sicherheit bei dem einen oder anderen Kunden Probleme gehabt, hätten wir nur ein DB im Angebot. Für die Kohle für ein Oracle-System (Lizenzen) hat sich manch ein Kunde MySQL mit entsprechenden (gekauften) Support ins Haus geholt + richtig "schöne" Hardware.

Zitat von Sherlock:

... aber setzt andere Clientversionen voraus, da ist es praktisch, wenn man die Ora-Clients umgehen kann.

Sehe ich auch so. Blos da wir bisher kein Probleme mit unserer Lösung haben welche den Client vorraussetzt besteht kein Zwang da was zu ändern. Für MySQL setzten wir selbst CoreLabs-SW ein.

Aber werden wir jetzt nicht sehr Off-Topic