Wieviele Querys braucht man

[Flogo]

Diese Frage klingt vielleicht etwas dumm aber es geht um folgendes:

Ich versuche mich grade mit einem Buch (Datenbankprogrammierung mit Delphi 6) in Datenbanken einzuarbeiten.
In diesem Buch steht man brauch für jede Operation (Insert, Update, Delete, GetByPK, GetByName, ....)
und für jede Tabelle eine Query. Also (QRY_InsertLand, QRYUpdateLand, ..., QRY_InsertKunde, QRY_UpdateKunde, ....)

Zu jeder Tabelle die nicht nur aus Pflichtfeldern besteht, muss man außerdem noch Prozeduren schreiben, die erstmal das SQL-Statement zusammenbasteln.

Hat das einen tieferen Sinn? Kan man nicht einfach eine Query pro Operation machen und je eine Prozedur, die die SQL-Statements bastelt?

[Bernhard Geyer]

Zitat von Flogo:

Diese Frage klingt vielleicht etwas dumm aber es geht um folgendes:

Ich versuche mich grade mit einem Buch (Datenbankprogrammierung mit Delphi 6) in Datenbanken einzuarbeiten.
In diesem Buch steht man brauch für jede Operation (Insert, Update, Delete, GetByPK, GetByName, ....)
und für jede Tabelle eine Query. Also (QRY_InsertLand, QRYUpdateLand, ..., QRY_InsertKunde, QRY_UpdateKunde, ....)

Zu jeder Tabelle die nicht nur aus Pflichtfeldern besteht, muss man außerdem noch Prozeduren schreiben, die erstmal das SQL-Statement zusammenbasteln.

Hat das einen tieferen Sinn? Kan man nicht einfach eine Query pro Operation machen und je eine Prozedur, die die SQL-Statements bastelt?

Freilich Machen das selbst genauso. Haben es auch noch so aufgebaut das mittels Bridge-Pattern mehrer DB-System unterstützt werden.

[Sharky]

Hai Flogo,

ich würde die Frage jetzt ersteinmal so beantworten:

Du brauchst für jede Tabelle auf die gleichzeitig zugegriffen wird ein eigenes Query.

Beispie:
Du hast 2 DBGrid die den Inhalt aus zwei Tabellen anzeigen und noch einige DBEdits die den Inhalt aus einer dritten Tabelle anzeigen. In diesem Fall brauchst Du 3 Querys.

Wenn Du jetzt noch zusätzliche Operationen (Insert,Update..) mit irgendeiner der drei Tabellen durchführen möchtest brauchst Du ein zusätzliches Query.

Es kann aber unter umständen besser sein für die "zusatz Operationen" mehrere Querys zu verwenden. Dies ergibt sich aber erst aus den Anforderungen des Programmes.


Wenn Du aber nur ein DBGrid hast in dem, z.B durch auswahl in einer ComboBox, der Inhalt von verschiedenen Tabellen angezeigt werden soll (nicht gleichzeitig) brauchst Du auch nur ein Query für das ganze.

[Flogo]

Zitat von Bernhard Geyer:

Freilich

bezieht sich das auf "macht das Sinn?" oder auf "Kann man das anders machen?"

Zitat von Bernhard Geyer:

Machen das selbst genauso. Haben es auch noch so aufgebaut das mittels Bridge-Pattern mehrer DB-System unterstützt werden.

Was sind Bridge-Pattern?


Ein möglicher Grund für die Art aus dem Buch ist mir noch eingefallen:
Was passiert, wenn während einer Abfrage eine andere gestartet wird? Ist dann die Query nicht "belegt"?


[Edit]
@Sharky
Danke! Das hab ich vorhin noch nicht gesehen.
Das heißt dann wohl ich muss erstmal meine Oberflläche entwerfen.

Wie ist das wenn ich mehrere Tabellen auf unterschiedlichen Tabsheets habe? Die kann ich dann doch behandeln wie unabhängige Tabellen, oder?
[/Edit]

[Edit2]
Wie ist das mit Verknüpfungstabellen? also Tabellen die eine n-zu-n-Verbindung in zwei 1-zu-n-Verbindungen auflösen?
[/Edit2]

[Bernhard Geyer]

Zitat von Flogo:

Zitat von Bernhard Geyer:

Freilich

bezieht sich das auf "macht das Sinn?" oder auf "Kann man das anders machen?"

Man wird, wenn man komplexere DB-Anwendungen entwickelt sich nicht mehr auf DB-Sensitive Controls und gebundene Datenmenge verlassen sondern alles "per Hand" erledigt.

Zitat von Flogo:

Zitat von Bernhard Geyer:

Machen das selbst genauso. Haben es auch noch so aufgebaut das mittels Bridge-Pattern mehrer DB-System unterstützt werden.

Was sind Bridge-Pattern?

Brücken-Muster

Zitat von Flogo:

Ein möglicher Grund für die Art aus dem Buch ist mir noch eingefallen:
Was passiert, wenn während einer Abfrage eine andere gestartet wird? Ist dann die Query nicht "belegt"?

Ja. Deshalb mußt du in solch einen Fall mit mehreren arbeiten. Aber ich les ja eh alles immer aus den Queries in eigene Objekte/Klassen.

[Igotcha]

Es kommt grds. darauf an, was Dein Programm machen soll.

Beispiel:

Du möchtest 2 Listviews mit Tabelleneinträgen füllen.

Dann reicht ein Query-Objekt, welches nacheinander 2 Abfragen durchführt, um die Listviews zu füllen.

Arbeiten tut das Programm dann mit den Daten, die im Listview stehen, da haben die Queries nichts mehr mit zu tun. Natürlich kann man bei Doppelklick auf einen Eintrag eine neue Query starten, um z.B. einen dritten LV, o.ä. zu bedienen.

Ich benutze zum Vorbelegen von Auswahlelementen in Formularen grds. nur eine Query, mit denen ich z.B: Dropdownlisten, etc. fülle. Dies mache ich mit der AddObject-Methode, wo dann gleich die DB-ID eines Eintrags mitgeliefert wird. Findet jetzt eine Useraktion statt, z.B. eine Dropdownlisten-Auswahl, frage ich die ID des Objekts ab und übergebe diese an ein (neues) Query-Objekt.


Anderes Beispiel:

In einer meiner Anwendungen muss ich für einen bestimmten Vorgang zur Darstellung von DB-Informationen 2 Query-Objekte verwenden.

Das sieht dann ungefähr so aus:

Delphi-Quellcode:

Query1.SQL.Text:='.....';
Query1.Open;
While not Query1.Eof do
begin
       Query2.SQL.Text:='.......';
       Query2.ParamByName('myParameter').AsString:=Query1.FieldByName('dummy').AsString;
       Query2.Open;
       While not Query2.Eof do
       begin
          Tueetwas mit den Daten aus Query2;
       end;
end;

In diesem Beispiel braucht man 2 Query-Objekte, da während des Vorgangs auch 2 Datenquellen benötigt werden.

Gruß Igotcha

[Flogo]

Sorry ich glaub das ist zu hoch für mich.
Ich hab immer noch nicht verstanden ob das "per Hand" erledigen jetzt für eine oder viele Query spricht.
Mit dem Wikipedia-Artikel fange ich auch nicht so viel an, weil ich mich zum einen nicht mit diesen Diagrammen auskenne und zum anderen die praktische Umsetzung dieses Prinzips in einer Datenbank nur erahnen kann.

Zitat:

Deshalb mußt du in solch einen Fall mit mehreren arbeiten. Aber ich les ja eh alles immer aus den Queries in eigene Objekte/Klassen.

Was tun diese Klassen dann mit den Daten? Ich hatte vor die Daten per Query in Records zu lesen, aber das würde die Frage nach den Querys ja nicht beantworten.


[Edit]
@Igotcha
Vielen Dank! Ich glaube zusammen mit Sharkys Post ist das genau das was ich wissen wollte.

[/Edit]

[Bernhard Geyer]

Zitat von Flogo:

Was tun diese Klassen dann mit den Daten? Ich hatte vor die Daten per Query in Records zu lesen, aber das würde die Frage nach den Querys ja nicht beantworten.

Wenn Du z.B eine einfache Adressveraltung hast. So könntest Du jeden Tabelleneintrag als Instanz einer Klasse TAdresse repräsendieren wobei diese Klasse sich sowohl speichern als auch laden könnte. Willst Du jetzt alle "Müllers" auslesen so bekommst du von deiner DB-Schnittstelle eine Objektliste von TAdresse (z.B in einer Klasse TAdressen). In dieser Klasse hast du z.B. eine Methode MakeSerienbrief um z.B. einen Serienbrief zu erzeugen.

[Flogo]

Ahhh! Ich glaub jetzt hab ichs verstanden
Wäre die Query in dem Fall dann Teil der Klasse TAdresse?

[r_kerber]

Zitat von Flogo:

Wäre die Query in dem Fall dann Teil der Klasse TAdresse?

Ich würde Datenbankklasse (mit Query) und Fachklasse (TAdressen) strikt voneinander trennen. Also in etwa so:

• DB-Abfrage mit Query
• Fachklasse mit Daten befüllen (Getter/Setter)

Dann ist es der Adressenklasse völlig egal, wo die Adreßdaten herkommen (DB, XML, SOAP, Text-Datei, manuelle Eingabe, ...)