Generelle Frage zur Verteilung von Datenbankkomponenten

[F.W.]

Entschuldigt die schlechte und sicher falsche Einordnung der Datenbank und Zugriffsart, aber ich weiß nicht was ich da angeben soll ^^ Hab mit Datenbanken nicht so viel zu tun.

Hintergrund:
Ich arbeite gerade an einer kleinen Kunden und Rechnungsverwaltung. Diese besteht aus den Tabellen Kunden, Rechnungen und Leistungen.
Jede Leistung hat eine RNr und ist somit einer Rechnung zuordenbar und jede Rechnung wiederum hat eine KNr für die Identifikation zum Kunden.
Ich habe schon Beim Programmieren viele Kapitel von Büchern und Tutorials über Datenbankeneinstieg gelesen, aber immer wenn ich dann selbst mal eine Anwendung mit DBs schreibe, stellen sich mir nun einige Fragen:

Zitat:

1. Ist wirklich ein Datenmodul für alle Datenbankzugriffskomponenten empfehlenswert?

Ich verliere immer leicht den Überblick, wenn sich so viele Kompos auf so einem Datenmodul befinden. Ich weiß nachher nicht mehr welche Tables, DataSources und Querys zu welchem Formular, welcher Abfrage usw. gehören. Obwohl ich meinen Komponenten versuche aussagekräftige Namen zu geben.

Zitat:

2. Ist es gut für die gesamte Anwendung (abgesehen von Abfragen) nur eine einzige Table und DataSource-Komponente pro Tabelle zu verwenden? In meinem Fall eben die drei für K, R und L?

Ich stelle mir das eigentlich so vor, z.B. für die Kundendatenbearbeitung gibt es ein Formular, welches seine Table oder Querykompo und DataSources hat und dann quasi recht modular aufgerufen werden kann, den Eintrag in der DB per Locate o.ä. ansteuert und bearbeiten kann (so wären bspw. auch mehrere Instanzen des Formulars möglich). Aber wenn ich dann etwas an der DB ändere, bekommen das die anderen Tables ja nicht so ohne weiteres mit?!

Zitat:

3. Wenn ich die Kompos auf einem Datenmodul platziere habe ich immer so ein schlechtes Gewissen, wenn ich dann in deren Ereignissen direkt auf eine global deklarierte Form (wie z.B. das Hauptformular oder bspw. das Kundendatenformular von 2.) zugreife. denn wenn ich wirklich den Umbau machen würde, dass das Kundenform nur instantiiert wird, wenn es gebraucht wird, würde das mit den Ereignissen von TTable und co auf dem Datamod ja nicht mehr klappen. Was ist also zu tun?

Zitat:

4. Ich habe eine Abfrage für Brutto und Netto Summe einer Rechnung. Diese ergibt sich ja aus der Summe der Leistungen (Felder Menge*Einheitspreis) die die jeweilige Rechnungsnummer haben. D.h. ich habe eine Abfrage für 2 Werte pro Rechnung. Ist es sinnvoll dafür eine eigene T(ADO)Query zu benutzen, die eben nur die beiden Felder liefert? (Die Abfrage ist mit Parametern :RNr versehen, so dass auch wirklich nur ein Datensatz zurückgegeben wird) Oder gibt es da noch andere Möglichkeiten? (Muss leider so geschehen, da ich die Daten in einen Treeview einlese, in dem zu jedem Kunden die Rechnungen aufgelistet sind und diese die Aufschrift mit Netto/Bruttosumme bekommen müssen

Die ersten drei Fragen hängen ja im Grunde genommen irgendwie zusammen. Mir fehlt nur jemand, der mir mal sagt, was sinnvoll oder gar professionell ist und wie man die Verteilung dieser Komponenten richtig organisiert. Das haben Tutorials und Bücher bisher leider noch nicht geschafft.

Mein Bestreben ist eben eine Modularisierung der einzelnen Formulare (Kundendaten, Rechnung+Leistungen) damit alles übersichtlich bleibt und man zur Not mal etwas ganz neues mit einem alten Tauschen kann. Ich mag nicht, wenn alles mit einander endlos verstrickt ist.

[EDIT]Tippfehler in Titel geändert

[Hansa]

Zitat:

Zitat von F.W.

Zitat:

1. Ist wirklich ein Datenmodul für alle Datenbankzugriffskomponenten empfehlenswert?

Ich verliere immer leicht den Überblick, wenn sich so viele Kompos auf so einem Datenmodul befinden. Ich weiß nachher nicht mehr welche Tables, DataSources und Querys zu welchem Formular, welcher Abfrage usw. gehören. Obwohl ich meinen Komponenten versuche aussagekräftige Namen zu geben.

Ein Datenmodul ist doch gerade dafür da, diese Geschichten und die Forms etwas zu entflechten. :shock: Bei drei Tabellen ist es wohl nicht übertrieben, drei Datasets, TDatabase, TTransaction etc. im Datenmodul zentral zu verwalten ? Das Datenmodul hat ja noch mehr Vorteile. Z.B. gibt es ein Oncreate, wo man (sogar zentral) allen Forms eine DB zuordnen kann. Manchmal sieht man Forms, bei denen die Datasets etc. auf jeder Form liegen. Was soll dieser Firlefanz ?

[mschaefer]

Tja es gibt für vieles verschiedenen Herangehensweisen:

Meine Variante ist die Transaktionen und Queries im Datamodule zu halten. Die DataSources lege ich aber auf die Forms, da ich ab und an auf das DataSourceOnChage-Ereignis regieren muß. Diese Routine brauche ich aber im Formular, da damit Anzeigeeinstellungen verändert werden.

Grüße // Martin

[F.W.]

Nun gut, aber nehmen wir mal an, ich habe ein Formular für die Kundendaten. Wenn ich dieses jetzt mehrmals erzeuge um mehrere Kunden gleichzeitig anzuzeigen bzw. zu bearbeiten (manchmal möchte man vlt von einem etwas übernehmen, also einer bearbeiten den anderen nur so offen), wie würde ich da heran gehen?

Wenn alle Formulare auf Table und Datasource im Datenmodul zugreifen, verstellt doch das eine Formular immer den Datensatz vom andern mit oder?
Und wenn ich von allen Formularen die etwas mit den Kundendaten zu tun haben gleichzeitig verschiedene Kunden öffnen möchte? dann komme ich um ein zweites oder drittes Paar Table und DataSource Komponenten nicht herum oder? Sonst würde mir doch auch immer wieder die Ansicht verstellt?

[Echtet]

Hallo F.W.

ich verstehe, was Du möchtest. ich kenne dieses Verhalten unter SAP als Arbeiten mit mehreren Modi (Fenstern). Also z.B. Kunde X anzeigen lassen und in einem weiteren Fenster Kunde y ändern.

Ich habe für mich nur die Möglichkeit gefunden, meine Querie für jedes Fenster dynamisch zu erzeugen, eine dynamisch erzeugte Transaktion zu verwenden und die SQL-Befehle zu übergeben.

Mit statisch eingebundenen DB-Komponenten konnte ich das gewünschte Verhalten nicht realisieren. Ich hätte zuviele Komponenten prophylaktisch anlegen müssen und hätte sicher irgendwann die Übersicht verloren.

Falls jemand einen besseren Vorschlag hat, wäre ich auch glücklich....

Gruß,
echtet

[F.W.]

Zitat:

Zitat von Echtet

Mit statisch eingebundenen DB-Komponenten konnte ich das gewünschte Verhalten nicht realisieren. Ich hätte zuviele Komponenten prophylaktisch anlegen müssen und hätte sicher irgendwann die Übersicht verloren.

So geht es mir zur Zeit auf meinem Datenmodul. Daher würde ich eben gern die Komponenten auf die Formulare verteilen, von denen sie genutzt werden.
Aber ich weiß eben nicht, was das für Vor-/Nachteile mit sich bringt. Sicher kann ich die Datenanbindung jetzt auf Vor- und Nachteile unsersuchen, aber ungewiss ist, ob ich beim Weiterentwickeln dann mit dieser Aufspaltungstechnik/Modularisierung Probleme bekomme. Und um das zu prognostizieren habe ich zu wenig Erfahrung.

[Echtet]

Hallo F.W.

Vielleicht hilft Dir folgender Quellcode beim Testen, ob dies Deinen Vorstellungen entspricht:

Annahme, IBX-Komponenten, aber die anderen Kompos funktionieren analog. Ich werfe keine DB-Komponenten auf die Formulare (Ausnahme: Im DataModule die Komponente IBDatabase.

In den Formularen rufe ich z.B. folgende Routine auf:

Delphi-Quellcode:

procedure NotizErfassen;
var i, AnzahlNotizen : integer;
    Query:TIBQUERY;
    Transaktion : TIBTransaction;
    SQL : string;
begin
  hLog.Add('');
  hLog.Add(DateTimetoStr(now) + ': ' + '***** Notiz erfassen *****');
  AnzahlNotizen := frmMain.AdvCodeListNotizen.CodeBlocks.Count;
  frmMain.AdvCodeListNotizen.CodeBlocks.Add(DateTimeToStr(Now));
  for i := 0 to frmMain.MemoNotizen.Lines.Count  do
  begin
    frmMain.AdvCodeListNotizen.CodeBlocks.Items[AnzahlNotizen].Code.Add(frmMain.MemoNotizen.Lines[i]);
  end;

 //sichern der Notizen in Tabelle TBLNOTIZEN

  //Queryobjekt unbd Transaktion erzeugen
  Query := TIBQUERY.create(nil);
  Query.Database := DataModule1.IBDatabase; //Datenbank zuordnen
  Transaktion := TIBTransaction.Create(NIL); //Transaktion dyn. erzeugen
  Transaktion.DefaultDatabase := DataModule1.IBDatabase; //Datenbank zuordnen
  Transaktion.AllowAutoStart := False; //Transaktionen müssen explizit gestartet werden
  Query.Transaction := Transaktion; //Transaktion zuordnen
  Transaktion.StartTransaction;  //Transaktionsbeginn

  if Length(frmMain.MemoNotizen.Text) > 0 then
  begin
    SQL := 'insert into tblnotizen (id, notiz) '
            + 'values (gen_id( gen_tblnotizen_id,1),'
            + ':Memo' + ')';
    Query.sql.Text := SQL;
    Query.ParamByName('Memo').asBlob := frmMain.MemoNotizen.Text;

    //Query ausführen
    Try
      Try
        Query.ExecSQL;  //Abfrage ausführen
      Finally
      end; //Finally
    EXCEPT
      on E:Exception do
      begin
          StatusMeldung(rot, 'Fehler beim Anlegen der Notizen! (Ausführen der Abfrage fehlerhaft)');
          hLog.Add(DateTimetoStr(now) + ': ' + 'SQL-Befehl: ' + SQL);
          Transaktion.Rollback;
          Raise;
      end;
    END; //Except

  //Query und Transaktion beenden
  Try
    Try
      Transaktion.Commit;
      StatusMeldung(gruen, 'Notiz wurde erfolgreich gesichert');
    Finally
      frmMain.MemoNotizen.Clear; //Anschließend löschen
      Query.free;
      Transaktion.Free;
      Screen.Cursor := crDefault;
    end; //Finally
  EXCEPT
    on E:Exception do
    begin
        StatusMeldung(rot, 'Sicherung der Notiz nicht möglich -> Rollback der Transaktion!');
        Transaktion.Rollback;
        Raise;
    end;
  END; //Except

  end  //if Length(MemoNotizen.Text) > 0 then
  else
  begin
    if Length(frmMain.MemoNotizen.Text) = 0 then
    begin
      StatusMeldung(rot, 'Notiz darf nicht leer sein!');
    end;
  end; //else
  NotizenLesen; //zum Aktualisieren
end;

Viele Grüße,

Echtet

[F.W.]

Zitat:

Zitat von Echtet

Vielleicht hilft Dir folgender Quellcode beim Testen, ob dies Deinen Vorstellungen entspricht:

So denke ich es mir eben auch. Die Datenbankverbindungskomponente (ADOconnection) liegt im Datenmodul, oder irgendwo, wo alle jederzeit drauf zugreifen können. Und von jedes Formular, das auf die Datenbank zugreifen möchte kommt dann eben Table, Query und DataSources.
Aber dann habe ich eben das "Problem", dass ich mich um die Aktualisierung in allen anderen Datenbankansichten selbst kümmern muss oder?

Außerdem habe ich dieses Mal voll auf die Nutzung der Datensensitiven Steuerelemente gebaut. Um mir eben etwas Tipparbeit zu ersparen und den Datenbankkomfort nutzen zu können.

Ein Beispiel: Jede Rechnung ist ein Eintrag in der RechnungenDB und in der LeistungenDB stehen alle Leistungen. Mit einander verknüpft durch Leistungen.RechnungsNr. Legt der Nutzer eine neue Rechnung an, muss er ja die Rechnungsnummer vergeben und die Rechnung fest ins System eintragen, sonst können die Leistungen ja nicht auf diese Rechnung (Rechnungsnummer) erstellt werden. Wie kann man das lösen? Wenn ich nicht gerade eine eigene Klasse schreiben möchte, die die Leistungen-Felder hat, an z.B. ListView-Einträge angehangen wird und dann mit Rechnug alles auf einmal eingetragen wird?
Ich meine, wenn ich eine eigene Klasse schreibe kann ich mir die Datenbanken ja gleich sparen, oder sehe ich das falsch?

[mkinzler]

Wenn du unbedingt öchtest kannst du ja mit verteilten Datenmodulen arbeiten. Die Frage ist nur ob diese dann mehr Probleme schaffen, als sie 1. Moment zu lösen scheinen.

[globetrotter77]

tja, das ist wieder mal eine richtig schöne, klassische Philosophiefrage, auf die es einfach keine einfache Antwort gibt.
Ich mache es meistens so, dass ich die eigentliche Verbindung zur Datenbank im für alle zentralen Datenmodul aufbaue. Ebenfalls dorthin kommen diejenigen Komponenten, die nur so ne Art temporäre Bedeutung haben, aber für alle vorhanden sein sollten. Beispielsweise Tabellen zum schnellen Nachschlagen. Da ich normalerweise nicht gleichzeitig an verschiedenen Datensätzen der selben Tabelle arbeite, stelle ich auch noch jeweils einen Table in der normalerweise verwendeten Sortierung dort hinein. Wenn ich dann unterwegs mal was in der selben Tabelle nachschauen muss, verwende ich eine formulareigene Komponente dafür. Damit behalte ich meine aktuelle Position bei und habe trotzdem Zugriff auf das, was ich benötige. Und die Übersicht versuche ich eher durch sprechende Namen herzustellen.

Aber wie du schon richtig sagtest, musst du, falls du in mehreren Fenstern an der selben Tabelle rumbastelst, die zugehörigen Tables bzw. Queries natürlich jeweils im Formular mitführen, da sich ja sonst beispielsweise die aktuelle Satznr. ständig ändern würde.
Was Änderungen angeht, müsste es dann eigentlich langen, ab und zu mal Application.ProcessMessages aufzurufen (z.B. beim Activate), um die letzten Änderungen auch mitzubekommen.

Fazit: kommt halt wie immer wieder drauf an, was du eigentlich willst! :?