T
tuxedo
Gast
Hallo,
ich hab mal ne kleine Designfrage...
Ich plane ein kleines Tool zum verwalten von Vereinsmitgliedern und deren Bankverbindungen für die jährlichen Mitgliedsbeiträge. Ich hab jetzt hin und her überlegt, bin aber auf keinen grünen Zweig bzgl. der Datenstruktur gekommen. Speichern will ich die Daten in einer Postgres-DB. Soweit kein Problem. Anbindung erfolgt über iBatis mit entsprechendem JDBC-Treiber. Auch kein Problem. Aber ich hab noch keinen Schimmer wie ich meine Datenstruktur in der DB und auf der Java-Seite (von iBatis aus gesehen) aufbaue.
Gehen wir mal davon aus dass jedes Mitglied eine Bankverbindung hat und jeder seinen Beitrag selbst zahlt. Dann würde ich die Struktur wie folgt wählen:
Okay. Das ist noch easy. Damit kann ich eindeutig eine Liste mit Bankverbindungen ein Beiträge zum einziehen der Mitgliedsbeiträge erzeugen.
Jetzt hab ich aber den Fall dass es auch Familienbeiträge gibt:
- Einer Familie gehören bestimmte Mitglieder an.
- Die Familie zahlt zusammen einen Beitrag
- Es gibt pro Familie genau eine Bankverbindung
Hmm, ich hab's bis jetzt so gemacht:
Ich finde die Lösung nicht "optimal". Grund: Ob "Einzelmitglied" oder "Familienmitglied" geht nur aus der Konstellation der
Felder des Mitglieds hervor. Zudem hab ich an mehreren Stellen Beitrag und Bankverbindung referenziert. Wird die Konstelation dieser 3 Felder "verwurschtelt" stimmt gar nix mehr.
Mir kommt's so vor als ob ich mittlerweile den Walt vor lauter Bäumen nicht mehr sehe. Was ich letztendlich haben will ist eine Struktur die in sich schlüssig und eindeutig ist. Aber vielleicht hat ja jemand von euch nen anderen Blick auf die Sache und kommt auf ne bessere Lösung.
Gruß
Alex
ich hab mal ne kleine Designfrage...
Ich plane ein kleines Tool zum verwalten von Vereinsmitgliedern und deren Bankverbindungen für die jährlichen Mitgliedsbeiträge. Ich hab jetzt hin und her überlegt, bin aber auf keinen grünen Zweig bzgl. der Datenstruktur gekommen. Speichern will ich die Daten in einer Postgres-DB. Soweit kein Problem. Anbindung erfolgt über iBatis mit entsprechendem JDBC-Treiber. Auch kein Problem. Aber ich hab noch keinen Schimmer wie ich meine Datenstruktur in der DB und auf der Java-Seite (von iBatis aus gesehen) aufbaue.
Gehen wir mal davon aus dass jedes Mitglied eine Bankverbindung hat und jeder seinen Beitrag selbst zahlt. Dann würde ich die Struktur wie folgt wählen:
Code:
[Mitglied]
* Mitglied-ID
* Kontaktdaten
* Beitrag-ID (hier wird ein Beitrag referenziert)
* Bankverbindung
[Beitrag]
* Beitrag-ID
* Art
* Betrag
Okay. Das ist noch easy. Damit kann ich eindeutig eine Liste mit Bankverbindungen ein Beiträge zum einziehen der Mitgliedsbeiträge erzeugen.
Jetzt hab ich aber den Fall dass es auch Familienbeiträge gibt:
- Einer Familie gehören bestimmte Mitglieder an.
- Die Familie zahlt zusammen einen Beitrag
- Es gibt pro Familie genau eine Bankverbindung
Hmm, ich hab's bis jetzt so gemacht:
Code:
[Mitglied]
* Mitglied-ID
* Kontaktdaten
* Beitrag-ID (hier wird ein Beitrag referenziert)
* Familie-ID (hier wird eine Familie referenziert)
* Konto-ID (hier wird eine Bankverbindung referenziert)
[Beitrag]
* Beitrag-ID
* Art
* Betrag
[Konto]
* Konto-ID
* Kontonummer
* BLZ
* Inhaber
[Familie]
* Familie-ID
* Name der Familie
* Elternteil_1 (hier wird eine Mitglied-ID referenziert)
* Elternteil_2 (hier wird eine Mitglied-ID referenziert)
* Beitrag-ID (hier wird ein Beitrag referenziert)
* Konto-ID (hier wird eine Bankverbindung referenziert)
Ich finde die Lösung nicht "optimal". Grund: Ob "Einzelmitglied" oder "Familienmitglied" geht nur aus der Konstellation der
Code:
* Beitrag-ID
* Familie-ID
* Konto-ID
Felder des Mitglieds hervor. Zudem hab ich an mehreren Stellen Beitrag und Bankverbindung referenziert. Wird die Konstelation dieser 3 Felder "verwurschtelt" stimmt gar nix mehr.
Mir kommt's so vor als ob ich mittlerweile den Walt vor lauter Bäumen nicht mehr sehe. Was ich letztendlich haben will ist eine Struktur die in sich schlüssig und eindeutig ist. Aber vielleicht hat ja jemand von euch nen anderen Blick auf die Sache und kommt auf ne bessere Lösung.
Gruß
Alex