Kreuztabelle erstellen

Hallo! Ich habe eine Mitgliedertabelle und eine Beitragstabelle und möchte die Die bezahlte Summe der Beiträge in die Mitgliedertabelle übernehmen. Wie kann ich das lösen? Muß bei beiden die gleiche ID sein?
Ich hoffe, Ihr könnt mir helfen.
Danke! Schwebebahn

und möchte die bezahlte Summe der Beiträge in die Mitgliedertabelle übernehmen.

Wozu soll das gut sein?

Muß bei beiden die gleiche ID sein?

Jein. Wie ebot schon schrieb, die IDs der beiden Haupttabellen müssen und können nicht gleich sein, aber die ID eines Datensatzes der einen Tabelle wird als Fremdschlüssel in der anderen Tabelle für die Zuordnung benötigt. Und da muss natürlich die entsprechende selbe ID auftauchen. Der Fremdschlüssel in der Tabelle Beiträge ist dann im Vorschlag von ebot das Feld ID_BM.

Die Beiträge aus der Beitragstabelle werden NICHT mit in die Mitgliedertabelle genommen. Das wäre Murks. Dafür gibt es die schon genannte 1:n-Verknüpfung zwischen der Mitgliedertabelle und der Beitragstabelle (1 Mitglied kann n Beiträge gezahlt haben, deshalb 1:n).

Funktional bietet sich für so etwas ein Unterformular an. Hauptformular Mitglieder, Unterformular Beiträge.

@Cookievore, ja da hast du recht, es gibt einen großen Unterschied zwischen ID-Bezeichnung und ID-Inhalt. Die Übernahme des Beitrags in die Mitgliederliste wäre unsinnig (was mein Kommentar schon hinterfragt). Ich vermute aber, das OP damit eine Zahlungsbestätigung erreichen will (?). Aber wie schon geschrieben, ohne weitere Informationen ist das stochern im Nebel.

@Schwebebahn, wenn du eine Beziehung zwischen den Tabellen hergestellt hast und in einem Formular mit Unterformular arbeitest, wird bei der Erstellung eines neuen Datensatzes, die Beziehungs-ID ID_BM automatisch hochgezählt.

@Schwebebahn , noch eine Ergänzung in Bezug auf die Überschrift. Eine Kreuztabelle ist in der Datenbankwelt ein spezielles Konstrukt zur Aggregierung von Daten (Summen, Anzahl, Mittelwerte, etc., zwei oder mehrdimensional). Außerdem gibt es den Terminus Kreuzprodukt bzw. kartesisches Produkt. Es ist nicht so richtig klar, ob Du so etwas meinst und wofür. Nach Deiner bisherigen Beschreibung braucht es keine Kreuztabelle. Aber eventuell ergänzt Du Deine Fragestellung diesbezüglich, wo und wie Deiner Meinung nach eine Kreuztabelle eine Rolle spielen soll.

Danke für die Hilfe; aber ich begreife die Kombination zwischen den Dateien nicht. Wäre schön, wenn jemand eine solche Variante hätte mit je 1 Datensatz und 1 oder 2 Feldern als ZIP

@Schwebebahn die Kommunikation kann doch nicht nur in eine Richtung laufen. Wie du aus den Beiträgen von @Cookievore, @RobertG und meiner Wenigkeit entnehmen kannst, fehlen von dir Aussagen, wie die Tabellen bei dir aufgebaut sind, was du erreichen willst bzw. was du dir vorstellst. Du kannst von deinen Tabellen Screenshots anfertigen (im Editiermodus) oder deine ODB hier hochladen. Zum Hochladen editiere deine Eingangsfrage. Schreibe keine Antwort, die nicht eine Antwort auf deine Eingangsfrage ist.

Also ich kenne jetzt deine Tabellen nicht, aber ich gehe mal davon aus,
dass jede Beitragsgröße (Beispiele: 10 €, 15 €, 20 €) beliebig viele Mitglieder haben kann/sollte.
Dann benötigst du eine Beziehung zwischen Beitrags(größe)-Tabelle zu Mitglieder-Tabelle.

Eine gleiche ID ist auf jeden Fall zu vermeiden. Es könnte so aussehen:

Beitragstabelle
ID_Beitrag

Mitgliedertabelle
ID_Mitglieder

ID_BM

Die IDs sind als Feldtyp = Integer[INTEGER] anzulegen.

Die IDs ID_Beitrag und ID_Mitglieder sind die Keys und zählen automatisch.
Die ID_Beitrag wird mit der ID_BM in Beziehung gesetzt (1:n).

Ohne genaue Kenntnisse der DB-Strukture läßt sich leider von meiner Seite nicht mehr sagen.

Ich hoffe es hilft dir weiter.

Vermutlich ist das Ganze eine n:m-Beziehung, da von einer “Summe der Beiträge” die Rede ist.

Zuerst einmal: Die Summe wird nirgendwo eingetragen. Jeder gezahlte Beitrag wird schön mit Datum und MitgliedID verbucht. Aus dieser separaten Tabelle wird anschließend für jedes Mitglied die Summe der gezahlten Beiträge ermittelt und mit der Summe der zu zahlenden Beiträge verglichen.

Du brauchst:

Tabelle Mitglied, Tabelle Beiträge, Tabelle rel_Mitglied_Beiträge (in der die Schlüsselfelder der ersten beiden Tabellen gemeinsames Schlüsselfeld sind. Aus diesen Tabellen ziehst Du die Summe der nötigen Beiträge pro Mitglied.

Tabelle Beitragszahlung, in der die Mitglieds_ID als Fremdschlüssel steckt, außerdem noch ein Datum und ein Betrag. Hier landen alle Zahlungseingänge.

Aus den der Summe der zu zahlenden Beiträge Minus der Summe der erbrachten Beiträge ermittelst Du das Soll für jedes Mitglied.

@RobertG , m:n kann man machen und ist sicher die sauberere Lösung, gerade, wenn es um Beitragssätze ginge, wie es von @Hrbrgr auch schon anklang. m:n passt aber nicht mehr, wenn aus der Beitragssatz- eine Beitrag-bezahlt-am-Tabelle wird. So eine Zeile kann keine m Einträge in der Mitgliedertabelle haben, sondern nur genau 1. Korrigier mich, wenn ich falsch liege. Datum und gezahlter Betrag gehören dann auch in die Tabelle rel_Mitglied_Beitrag(ssatz).

m:n-Relation ist gleich mal mind. 1 Level anspruchsvoller. Schön, wenn man das verinnerlicht hat, aber auch eine erheblich Hürde, wenn man sich das erste Mal an so etwas dran macht. IMO reicht es aus, in der Beitragstabelle ein Feld Beitrag (Sollbetrag) und ein Feld Bezahlt_Datum vorzuhalten und bei 1:n zu bleiben. Auch so kann man je Mitglied ermitteln, ob offene Beiträge existieren. Ist aber auch alles etwas spekulativ, solange der OP keine weiteren Infos bereitstellt.

Die Beitragszahlungen kommen in eine gesonderte Tabelle. Ist eine 1:n-Beziehung zu den Mitgliedern und nicht gekoppelt mit dem Sollbeitrag. Da können dann beliebig viele Datensätze zu einem Mitglied gespeichert werden, weil der Primärschlüssel ein AutoIncrement-Schlüssel ist, der nirgendwo anders vorkommt.

Ich gehe eben davon aus, dass es sich um verschiedene Beitragsarten (Mitgliedsbeitrag, Beitrag für Lagerung von Material, Abteilungsbeitrag …) aus der Tabelle “Beiträge” handelt und dass nicht der gesamte Beitrag auf einmal entrichtet wird, sondern summarische Zahlungen z.B. vierteljährlich erfolgen.

Wenn es nur eine Beitragsart gibt, dann kann die natürlich direkt in der Mitgliedertabelle stehen …

Die Beitragszahlungen kommen in eine gesonderte Tabelle. Ist eine 1:n-Beziehung ..

Aha. Danke für die Bestätigung. Das ist ja auch die Ausgangssituation, die der OP beschreibt.

Bis auf den letzten Satz kann ich das nachvollziehen, aber

Wenn es nur eine Beitragsart gibt, dann kann die natürlich direkt in der Mitgliedertabelle stehen ...

entspricht nicht meiner Anregung im vorhergehenden Kommentar. Funktioniert IMHO auch nicht, da sicherlich mehrere Beitragszahlungen im Laufe der Zeit kommen werden. Ich kann nicht erkennen, woher Du das ableitest.

Es wäre mal langsam an der Zeit, dass der OP (@Schwebebahn) sich zu seinem Projekt äußert. Die Frage nach den gleichen IDs ist ja auch hinlänglich beantwortet.