Tabellen verknüpfen

[brunoM]

Hallo zusammen

Ich schreibe mein CRM-Programm um und wechsle einerseits von einer Absolute DB auf Firebird. Mittlerweilen hab ich mich für die FireDac-Komponenten entschieden, da scheinbar die UNIDAC-Komponenten nicht ganz kompatibel sind. Mittlerweile hab ich mich in FireDac eingearbeitet bzw. ich komme gut zurecht damit.

Die Hauptansicht des Adressmoduls besteht aus einem DBGrid, welches die Adressdaten anzeigt (können gefiltert, durchsucht usw. werden) - funktioniert gut.

Dazu gibt es eine Tabelle, wo Kontakte gespeichert werden - die Verknüpfung geschieht über den Primärschlüssel der Adress-Tabelle. Ich möchte nun in einem anderen DBGrid die Kontatdaten zu dem entsprechend im Adress-Grid selektierten Datensatz anzeigen. Beim Wechsel der selektierten Adresse sollen logischerweise auch die Daten der Kontakte wechseln.

Meine Frage wie löse ich das am Besten? Mit einer FDTable und entsprechender Filterfunktion oder über eine FDQuery-Komponent mit SQL-Anweisung und entsprechendem Parameter. Oder löst man das anders?

Danke im Voraus.

Bruno

[jobo]

Klassisch gibt es die Mastersource Eigenschaft. Dort konnte man für eine Subdatenmenge definieren, welche Master Datasource zu verwenden ist.
Weiß nicht, ob das mit den FD Komponenten noch genau so ist (oder ähnlich).

http://docwiki.embarcadero.com/RADSt...enge_verwenden

Ob man das überhaupt so macht, ist eine philosophische Frage. Da Du Third Party data sensitive Components verwendest, wäre die Antwort vermutlich ja.

Würdest Du mit anderen Verfahren arbeiten, dann wäre das "Mastersource" Verfahren wohl nicht das richtig.
Auch mit den FD Komponenten kann man das Verhalten zu Fuß erreichen, in dem man das Subdataset neu filtert, wenn das Hauptdataset ein RecordChange hat (genau event Bezeichnung bei FD kenne ich nicht)

[Slipstream]

Zitat:

Zitat von brunoM (Beitrag 1361474)

Dazu gibt es eine Tabelle, wo Kontakte gespeichert werden - die Verknüpfung geschieht über den Primärschlüssel der Adress-Tabelle. Ich möchte nun in einem anderen DBGrid die Kontatdaten zu dem entsprechend im Adress-Grid selektierten Datensatz anzeigen. Beim Wechsel der selektierten Adresse sollen logischerweise auch die Daten der Kontakte wechseln.

Eine andere Möglichkeit wäre, ein View in Firebird anzulegen, das schon alles enthält, was du darstellen möchtest. Ich hab hier z.B. eine Datenbank, in der Einträge einer Tabelle die Integer-Spalte Kategorie enthalten, die auf die Tabelle Kategorien verweist. Um ein View zu machen:

Code:

CREATE OR ALTER VIEW V_SAMMLUNG(
    ID,
    TITEL,
    KATEGORIE,
    INHALT)
AS
select

SAMMLUNG.ID_SAMMLUNG,
SAMMLUNG.TITEL,
KATEGORIEN.KATEGORIE,
SAMMLUNG.BESCHREIBUNG

from SAMMLUNG

inner join KATEGORIEN on KATEGORIEN.ID_KATEGORIEN = SAMMLUNG.KATEGORIE
;

Dieses View kann ich genauso mit einem Query öffnen wie eine Tabelle. Dabei setze ich im Query ReadOnly auf True. Und ich muss mich nicht mehr um Verknüpfungen im Delphi-Programm kümmern.

[jobo]

Ein View liefert vermutlich nicht das gewünschte Ergebnis. Er könnte zwar eine Mischmenge präsentieren, aber das löst nicht das Problem der Nachführung der Daten bei Änderung des Hauptdatensatzes.

[Slipstream]

Zitat:

Zitat von jobo (Beitrag 1361486)

Ein View liefert vermutlich nicht das gewünschte Ergebnis. Er könnte zwar eine Mischmenge präsentieren, aber das löst nicht das Problem der Nachführung der Daten bei Änderung des Hauptdatensatzes.

Was verstehst du unter Nachführung der Daten? Ich kenn den Ausdruck leider nicht. Meinst du vielleicht das Aktualisieren der Datenmenge im View-Query?

Nachtrag: Meine Views liefern die gewünschten Ergebnisse. Das ist keine Vermutung, sondern wurde mehrfach empirisch überprüft.

[p80286]

Zitat:

Zitat von jobo (Beitrag 1361486)

Ein View liefert vermutlich nicht das gewünschte Ergebnis. Er könnte zwar eine Mischmenge präsentieren, aber das löst nicht das Problem der Nachführung der Daten bei Änderung des Hauptdatensatzes.

Kommt darauf an wie Du so etwas realisierst

Code:

select MainID,Adrdata.Feld1,AdrData.Feld2
from Kontakte join Adressen on (Kontakte.MainID=Adresse.MainID)

Je nachdem wie normalisiert die DB ist, kannst Du mit einem View den Zugriff schon vereinfachen.
Um Mißverständnissen vorzubeugen, die Oberfläche benötigt natürlich ein "Datenänderungs"-Event, daß dann die entsprechenden Änderungen/Abfragen anstößt.

Gruß
K-H

[jobo]

Zitat:

Zitat von p80286 (Beitrag 1361513)

Kommt darauf an wie Du so etwas realisierst

Je nachdem wie normalisiert die DB ist, kannst Du mit einem View den Zugriff schon vereinfachen.
Um Mißverständnissen vorzubeugen, die Oberfläche benötigt natürlich ein "Datenänderungs"-Event, daß dann die entsprechenden Änderungen/Abfragen anstößt.

Ich habe den TE so verstanden, dass er 2 getrennte Datenquellen hat (Master/Detail), wobei eben die Detaildatenquelle automatisch nachgeführt / synchron angezeigt werden soll, sobald die Masterquelle den activen Datensatz ändert. Ein View würde an der Aufgabenstellung nichts ändern/lösen.
Ansonsten bin ich der letzte, der etwas gegen die Verwendung von Views sagen würde. Meinetwegen kann man ausschließlich Views verwenden.

[Slipstream]

Zitat:

Zitat von jobo (Beitrag 1361575)

Zitat:

Zitat von p80286 (Beitrag 1361513)

Kommt darauf an wie Du so etwas realisierst

Je nachdem wie normalisiert die DB ist, kannst Du mit einem View den Zugriff schon vereinfachen.
Um Mißverständnissen vorzubeugen, die Oberfläche benötigt natürlich ein "Datenänderungs"-Event, daß dann die entsprechenden Änderungen/Abfragen anstößt.

Ich habe den TE so verstanden, dass er 2 getrennte Datenquellen hat (Master/Detail), wobei eben die Detaildatenquelle automatisch nachgeführt / synchron angezeigt werden soll, sobald die Masterquelle den activen Datensatz ändert. Ein View würde an der Aufgabenstellung nichts ändern/lösen.
Ansonsten bin ich der letzte, der etwas gegen die Verwendung von Views sagen würde. Meinetwegen kann man ausschließlich Views verwenden.

Wenn du ein View hast, das im Gegensatz zur Original-Mastertabelle nicht nur die Id eine Subtabelle anzeigt, sondern den Eintrag aus der gewünschten Spalte, dann wird das auch so im DBGrid angezeigt. Wenn es jedoch darum geht, daß das Scrollen in der View-Datenmenge gleichzeitig zu einem Anzeigen des entsprechenden Datensatzes in der Original-Datenmenge sowie in der Sub-Datenmenge führt, ist es erforderlich, im OnScroll-Handling der View-Datenmenge die beiden anderen zu lokalisieren.

Wir habne hier eine Anwendung, die in einem DB-Grid im oberen Bereich des Formulars die View-Datenmenge anzeigt, während beim Scrollen dieser View-Datenmenge automatisch im unteren Bereich die Feldinhalte in DB-sensitiven Komponenten (TDBEdit usw.) angezeigt werden. Die Inhalte der jeweiligen Subtabellen-Felder werden in jeweils einer TDBLookupComboBox angezeigt. Dort trägt man in der Eigenschaft DataSource den Namen der Mastertable-Datasource ein, entsprechend in DataField das Feld, das den FK (Foreign Key) für die Subtabelle enthält. Der FK der Mastertabelle sollte der gesuchte PK der Subtabelle sein. Nun trägt man in ListSource das DataSource der Subtabelle ein, in KeyField kommt das Feld mit dem PK der Subtabelle, und in ListField das Feld, das in der TDbLookupComboBox angezeigt werden soll. Steht auch alle so in der Hilfe.

Die Anzeigen in TDbLookupComboBox werden beim Scrollen durch die Datenmenge der Mastertabelle automatisch aktualisiert. Zur Synchronisation zwischen View und Mastertabelle schreiben wir im AfterScroll des Views:

Delphi-Quellcode:

procedure TDatenModul.ViewMasterTabelleAfterScroll(DataSet: TDataSet);
begin
  MasterTabelle.Locate('ID_MASTER',ViewMasterTabelle.FieldByName('ID').AsInteger,[]);
end;

Hier wird das View nur dazu verwendet, eine lesbare Tabelle im Grid anzeigen zu können. Das Scrollen des Views lokalisiert automatisch den zugrundeliegenden Datensatz der Mastertabelle. Man könnte in ViewMasterTabelleAfterScroll auch einen SQL-Befehl reinschreiben, der immer nur den einen Datensatz selektiert. Bei einer großen Datenmenge ist das bestimmt günstiger, als ständig zwei nahezu gleiche Datenmengen im Speicher zu halten.

[jobo]

Zitat:

Zitat von Slipstream (Beitrag 1361615)

..
Wenn du ein View hast, ..

Wie gesagt, die Anforderungen des TE haben m.E. nichts mit einem View zu tun.
Ob zwei Datenmengen, die eine Master Detail Beziehung darstellen sollen, per View oder per Query oder Table angesprochen werden, sollte wurscht sein.
Da ich die gefragten Komponenten und ihre Properties nicht kenne sicherheitshalber der Hinweis, ich rede von einem View in der Datenbank, nicht einer Delphi Property oder sonst irgendwas.
Für den TE sind vermutlich eher die OnScroll Events der Schlüssel zum Erfolg.

[p80286]

[OT]
Das interessiert mich jetzt

Zitat:

Zitat von jobo (Beitrag 1361575)

Ich habe den TE so verstanden, dass er 2 getrennte Datenquellen hat (Master/Detail), wobei eben die Detaildatenquelle automatisch nachgeführt / synchron angezeigt werden soll, sobald die Masterquelle den activen Datensatz ändert.

soll heißen irgendwo auf meiner Oberfläche ändert sich ein Wert (Master), dann muß ich/mein Programm die Detail-Daten gesondert abholen? [select irgendwas from Detail where ID=Masterid]

Zitat:

Zitat von jobo (Beitrag 1361575)

Ein View würde an der Aufgabenstellung nichts ändern/lösen.

das käme mm nach auf Die Datenmenge an, ist sie klein genug würdest Du nur einmal über das MasterDetailview auf die DB zugreifen.

Oder welch schrecklicher Gedanke, schreiben wir aneinander vorbei?

Gruß
K-H
[/OT]

[Slipstream]

Zitat:

Zitat von jobo (Beitrag 1361623)

Da ich die gefragten Komponenten und ihre Properties nicht kenne sicherheitshalber der Hinweis, ich rede von einem View in der Datenbank, nicht einer Delphi Property oder sonst irgendwas.

Ist das durch mein Posting mit dem SQL-Beispiel nicht deutlich geworden, dass ich ebenfalls von einem DB-View geschrieben habe?

Zitat:

Zitat von p80286 (Beitrag 1361624)

Zitat:

Zitat von jobo (Beitrag 1361575)

Ein View würde an der Aufgabenstellung nichts ändern/lösen.

das käme mm nach auf Die Datenmenge an, ist sie klein genug würdest Du nur einmal über das MasterDetailview auf die DB zugreifen.

Wir machen das auch bei grossen Datenmengen mit Views. Sind entsprechende Indexe gesetzt, geht das auch ziemlich flüssig. Meistens wird ja sowieso vorher gefiltert, weil man nicht Millionen Datensätze gleichzeitig darstellen will. Bei grossen Datenbanken empfehlen wir zusätzlich den Einsatz eines Solid-State-Drives.

[p80286]

Zitat:

Zitat von Slipstream (Beitrag 1361615)

Das Scrollen des Views lokalisiert automatisch den zugrundeliegenden Datensatz der Mastertabelle.

Da ein View platt gesagt ein "Select der sich als Tabelle" tarnt ist, bringe ich "scrollen" nicht unbedingt mit ihm in Verbindung. Daten die oder in denen du scrollst, können aus einem View stammen müssen aber nicht.
Die Möglichkeit mit einem Cursor durch eine Ergebnismenge zu "scrollen" lasse ich jetzt mal außen vor.

Gruß
K-H

Edith:

Zitat:

Zitat von Slipstream (Beitrag 1361627)

Wir machen das auch bei grossen Datenmengen mit Views. Sind entsprechende Indexe gesetzt, geht das auch ziemlich flüssig. Meistens wird ja sowieso vorher gefiltert, weil man nicht Millionen Datensätze gleichzeitig darstellen will. Bei grossen Datenbanken empfehlen wir zusätzlich den Einsatz eines Solid-State-Drives.

Mir ging es um die Datenmenge, die vom Programm für die Anzeige vorgehalten wird. Ich sehe das sehr puritanisch, da ich der Meinung bin, der Speicher ist für die Datenverarbeitung da, nicht für die Oberfläche. Darum setze ich auch stillschweigend vorraus, daß bei in jedem Datenbankzugriff nicht mehr Daten über die Leitung gehen als notwendig.

[jobo]

Zitat:

Zitat von Slipstream (Beitrag 1361627)

Ist das durch mein Posting mit dem SQL-Beispiel nicht deutlich geworden, dass ich ebenfalls von einem DB-View geschrieben habe?

Ja, das ändert nichts daran, dass ich die Komponenten nicht kenne und es vielleicht missverständlich ist, was ich schreibe.

Ich denke der TE hat genug Material und man muss das hier nicht weiter unnötig aufblähen.

[Slipstream]

Zitat:

Zitat von jobo (Beitrag 1361631)

Ich denke der TE hat genug Material und man muss das hier nicht weiter unnötig aufblähen.

Soll das jetzt heissen, du machst diese Diskussion zu?

Zitat:

Zitat von p80286 (Beitrag 1361629)

Da ein View platt gesagt ein "Select der sich als Tabelle" tarnt ist, bringe ich "scrollen" nicht unbedingt mit ihm in Verbindung.

Ich schon.

Zitat:

Zitat von p80286 (Beitrag 1361629)

Daten die oder in denen du scrollst, können aus einem View stammen müssen aber nicht.

Wenn ich einer Query-Komponente - du kennst doch Query-Komponenten, oder? ein View zuweise, dann stammen die Daten, die in diesem Query vorgehalten werden, ohne Zweifel aus diesem View? Woher sollten sie deiner Mainung nach sonst stammen?

Zitat:

Zitat von p80286 (Beitrag 1361629)

Die Möglichkeit mit einem Cursor durch eine Ergebnismenge zu "scrollen" lasse ich jetzt mal außen vor.

Ich aber nicht. Egal welchen Datensatz aus dem View du anwählst, das Ereignis AfterScroll wird ausgelöst.

Zitat:

Zitat von p80286 (Beitrag 1361629)

Mir ging es um die Datenmenge, die vom Programm für die Anzeige vorgehalten wird. Ich sehe das sehr puritanisch, da ich der Meinung bin, der Speicher ist für die Datenverarbeitung da, nicht für die Oberfläche. Darum setze ich auch stillschweigend vorraus, daß bei in jedem Datenbankzugriff nicht mehr Daten über die Leitung gehen als notwendig.

Wo speichern deine Anzeige-Komponenten ihre Daten? Wird die Oberfläche beim Programmstart nicht in den Speicher geladen? Tut mir echt leid, aber ich kann deiner Argumentation nicht so richtig folgen. :cry:

[jobo]

Zitat:

Zitat von Slipstream (Beitrag 1361652)

Soll das jetzt heissen, du machst diese Diskussion zu?

Nein, vermutlich kann ich das gar nicht. Ich finde es nur nicht hilfreich für den TE, dieses Randthema weiter durchzukauen. Zumal er sich auch noch nicht weiter geäußert hat zu dem Stoff, der hier bereits vorliegt.