Zahlungseingänge von mehreren Kunden wie am besten abbilden in der Datenbank ?

jhjh

Bekanntes Mitglied
Hallo,
Über eine SQLite Datenbank (wird über eine Android App verwendet) verwalte ich immoment gut 100 Kunden. Die Datenbank besitzt bisher lediglich eine simple Tabelle, die die wesentlichen Kundendaten (ID, Name, Ort etc) verwaltet. Nun müssen die Zahlungseingänge von den Kunden auch noch gespeichert werden, aber ich bin mir nicht sicher wie ich das am geschicktesten in der Datenbank abbilden kann.
Die Kunden müssen jede Woche an einem bestimmten Tag die Summe X zahlen. Da die Kunden für einen bestimmten Zeitraum auch im Vorraus (oder auch im Nachhinein) bezahlen können, müssen die vergangenen Wochen, sowie die zukünftigen Wochen mit in die Datenbank rein. Hierfür werden die letzten 5 Monate und die nächsten 6 Monate berücksichtigt.
Mir fallen 2 Möglichkeiten an, wie ich das theoretisch realisieren könnte:

Möglichkeit 1
Für jeden Kunden wird eine eigene "Bezahl-Tabelle" nach folgendem Schema erstellt

Woche 1 -> Woche 2 -> Woche 3 -> Woche 4 -> Woche 5
Mai
Juni
Juli
Aug
Sep
Okt
Nov
Dez
Jan
Feb
März
April

So würde die Tabelle aus heutiger Sicht aussehen. Nach jedem Monat müssten die Tabellen dann dementsprechend automatisch angepasst werden. Als Werte sollen dann true (für gezahlt) und false (für nicht gezahlt) eingesetzt werden.

Möglichkeit 2
Ich erweitere meine bisherige Tabelle einfach um weitere "Bezahlt-Spalte". Für jeden Kunden wird ein String aus 0en und 1en erstellt, der die Zahlungsinformationen beeinhaltet. Jeder String besteht dabei dann aus 52 zeichen. Das erste Zeichen würde dann für die Bezahlung der ersten Woche im Mai stehen. Das letzte Zeichen würde dann für die letze Woche im April stehen.

Möglichkeit 2 erscheint mir hier geeigneter. Es gibt doch aber sichelich noch eine bessere Variante ?! Ich bedanke mich =)
 

mihe7

Top Contributor
Pauschal lässt sich so etwas nicht sagen (außer, dass Möglichkeit 1 keine ist ;)).

Grundsätzlich würde ich eine separate Tabelle vorschlagen, die neben der Kundennummer das Datum oder wenigstens Jahr und KW des Zahlungseingangs enthält. In dem Fall könntest Du z. B. auch den Betrag erfassen.

Im Einbenutzerbetrieb kann die von Dir beschriebene 2. Möglichkeit einen durchaus gangbaren Weg darstellen (Mehrbenutzer geht auch, da wird es aber schnell hässlich). Es stellt sich die Frage, wie der "Jahreswechsel" zu behandeln ist. Unabhängig davon: wenn Platz ein Faktor ist, kannst Du eine INTEGER-Spalte wählen und darauf 53 Bits abbilden (ein Kalenderjahr hat auch mal 53 Wochen).

Was nun der geeignetere Weg ist, hängt von den genauen Anforderungen ab. So wird beispielsweise bei der 2. Möglichkeit beim Suchen nach Bezahlstatus kein Index verwendet werden können, im Gegensatz zur oben skizzierten Vorgehensweise. Dann ist die Frage, ob man dann nicht auch eine separate Tabelle verwendet, weil man den Bezahlstatus nicht jedesmal mitladen möchte usw. usw.
 

jhjh

Bekanntes Mitglied
Hallo, danke erstmal für deine Antwort =)
Grundsätzlich würde ich eine separate Tabelle vorschlagen, die neben der Kundennummer das Datum oder wenigstens Jahr und KW des Zahlungseingangs enthält. In dem Fall könntest Du z. B. auch den Betrag erfassen
Der Betrag muss in meinem Fall nicht erfasst werden. Meinst du das mit der seperaten Tabelle in etwa so:
KnNr -> Datum
1 15.05.2018 (Zahlungseinang von KnNr 1 für den 15.05.2018)
1 22.05.2018
1 29.05.2018
..............................
..............................
..............................
2
2
2
..............................
..............................
..............................

Sehe ich das richtig, dass der Vorteil hierbei (gegenüber meiner 2. Möglichkeit) alleine darin besteht, dass der Bezahlstatus besser indixiert werdeb kann ? Da ich ja ansonsten den kompletten Bezahlstatus der ganzen 12 Monate eines Kunden aus der Tabelle laden müsste, um es (zB den String) anschließend im Programm aufzudrösel ?

Es stellt sich die Frage, wie der "Jahreswechsel" zu behandeln ist
Wieso sollte der Jahreswechsel ein Problem darstellen ? Es kann doch ganz normal weiter gehen !?

Es ist so gedacht, dass der User die Möglichkeit hat, zunächst die Kundendetails zu einem bestimmten Kunden aufrufen zu können. Anschließend wählt der User einen bestimmten Monat aus und erhält dann eine kleine Liste mit den Wochen und ob der Kunde gezahlt hat oder nicht
Woche_1 -> Ja
Woche_2 -> Ja
Woche_3 -> Ja
Woche_4 -> Nein
(Woche_5 -> Nein)
 

mihe7

Top Contributor
Meinst du das mit der seperaten Tabelle in etwa so:
Ja.

Sehe ich das richtig, dass der Vorteil hierbei (gegenüber meiner 2. Möglichkeit) alleine darin besteht, dass der Bezahlstatus besser indixiert werdeb kann ?
Im Allgemeinen nicht aber im konkreten Fall könnte dies durchaus sein.

Wieso sollte der Jahreswechsel ein Problem darstellen ? Es kann doch ganz normal weiter gehen !?
Naja, am Jahresende sind im Idealfall alle 52/53 Wochen als bezahlt markiert. Beim Jahreswechsel müsstest Du die Markierungen wieder aufheben. Wie unterscheidest Du dann, wenn ich im Voraus für den Januar 2019 bezahle?

zunächst die Kundendetails zu einem bestimmten Kunden aufrufen zu können. Anschließend wählt der User einen bestimmten Monat aus und erhält dann eine kleine Liste mit den Wochen und ob der Kunde gezahlt hat oder nicht
Wenn das alles ist, brauchst Du Dir keine großen Gedanken zu machen.
 

mrBrown

Super-Moderator
Mitarbeiter
Gibts nur Zahlungseingänge oder auch sowas wie Abonnements oder ähnliches?
 
Zuletzt bearbeitet:

jhjh

Bekanntes Mitglied
So, habe jezt wieder Zeit gefunden zu antworten =)
Danke nochmal für die Antworten, ich werde es wohl mit eine zusätzlichen Tabelle lösen.
Naja, am Jahresende sind im Idealfall alle 52/53 Wochen als bezahlt markiert. Beim Jahreswechsel müsstest Du die Markierungen wieder aufheben. Wie unterscheidest Du dann, wenn ich im Voraus für den Januar 2019 bezahle?
Hmm ehrlich gesagt versteht ich das immer noch nicht ganz. Nach jedem Monat werden die Monat um ein Monat nach oben "verschoben". Es wird also quasi unten ein Monat weggenommen und oben ein Monat hinzugepackt. Nach dem Jahreswechsel genau das gleiche.
Angenommen wir befinden uns in der ersten Dezemberwoche und du hättest alles bis einschließlich November bezahlt . Dann würde die Tabelle in etwa so aussehen:

(Alles ab Juli wird berücksichtigt)
KnNr -> Bezahlt
123 -> 01.07.18
123 -> 08.07.18
123 -> 15.07.18 <- Juli
123 -> 22.07.18
123 -> 29.07.18
...
... <- Aug, Sep, Okt,
...
123 -> 01.11.18
123 -> 08.11.18
123 -> 15.11.18 <- Nov
123 -> 22.11.18
123 -> 29.11.18
...
... <- Dez, Jan(2019),Feb(2019),März(2019),April(2019),Mai(2019), Juni(2019)
...
Solltest du jetz beispielsweise für 2 Monate im Vorraus (also für Dez & Jan) bezahlen, würde die Tabelle so aussehen:

KnNr -> Bezahlt
123 -> 01.07.18
123 -> 08.07.18
123 -> 15.07.18
123 -> 22.07.18
123 -> 29.07.18
...
...
123 -> 01.11.18
123 -> 08.11.18
123 -> 15.11.18
123 -> 22.11.18
123 -> 29.11.18

123 -> 01.12.18
123 -> 08.12.18
123 -> 15.12.18
123 -> 22.12.18
123 -> 29.12.18

123 -> 01.01.19
123 -> 08.01.19
123 -> 15.01.19
123 -> 22.01.19
123 -> 29.01.19
...
... <- Feb(2019),März(2019),April(2019),Mai(2019),Juni(2019)
...

Gibts nur Zahlungseingänge oder auch sowas wie Abonnements oder ähnliches?
Na jedenfalls kein richtiges Abonnement. Jeder Kunde erhält jede Woche ein Dienstleistung. Diese kann er wöchentlich, monatlich (Anfang oder Ende des Monats), oder halt auch beispielsweise quartalsweise bezahlen. Jeder Kunden kann aber auch jeder Zeit kündigen. Es geht im Grunde um das Entwickeln einer App für einen Zeitungsverlag. Jeder Zeitungshändler kann diese App benutzen, um sein Kunden zu verwalten.
 

mihe7

Top Contributor
Es wird also quasi unten ein Monat weggenommen und oben ein Monat hinzugepackt. Nach dem Jahreswechsel genau das gleiche.
Das Problem, das ich meinte, hätte sich ergeben, wenn Du ausschließlich über die KWs gegangen wärst und Du das vollständige letzte Jahr im Zugriff haben hättest wollen. Wenn Du durch "Verschiebung" dafür sorgst, dass Du stets nur die nächsten und die letzten 6 Monate im Zugriff hast, umgehst du das Problem natürlich - zumindest in der Praxis, denn ich glaube nicht, dass jemand in der Jahresmitte für das nächste Jahr bezahlt...

Dann würde die Tabelle in etwa so aussehen:
Ja, so macht man das üblicherweise :)
 

jhjh

Bekanntes Mitglied
Das Problem, das ich meinte, hätte sich ergeben, wenn Du ausschließlich über die KWs gegangen wärst und Du das vollständige letzte Jahr im Zugriff haben hättest wollen
Ah ok, verstehe!

Ich weiß jetzt erstmal Bescheid! Falls es noch zu Problemen kommen sollte, würde ich mich ggf nochmal melden.
Danke nochmal! =)
 

Thallius

Top Contributor
Ich würde gar nicht mit Wochen arbeiten sondern mit Tagen und einer Range. Also wenn der Kunde für die erste Woche bezahlt hast du die Einträge

Knd-ID, ErstarTag, LetzterTag, TerminDerZahlung, SummeGezahlt

Damit hast du später immer und alle Möglichkeiten. Du kannst jederzeit auch von wöchentlichen Zahlungen auf monatliche gehen oder tägliche, jährliche. Dir ist damit alles egal. Theoretisch kannst du es sogar noch weiter runterbrechen auf Stunden.
Was ist wenn ihr euer Bezahlmodell umstellt und es in Zukunft auch mögloch ist Stundeweise zu abbonieren? Dann schreibst Du deine ganze Software neu.

Gruß

Claus
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
E SQLite Datenbank durchsuchen mit mehreren Suchbegriffen Datenbankprogrammierung 10
S MySQL Befüllen von mehreren Spalten Datenbankprogrammierung 1
I JPA Liste mit mehreren Entitäten Datenbankprogrammierung 22
R Transaktionen von mehreren Anwendungen aus - JDBC Datenbankprogrammierung 3
M Problem mit mehreren Datasourcen Datenbankprogrammierung 3
D Oracle Funktion mit mehreren Out Parametern ausführen? Datenbankprogrammierung 3
L MySQL Datenbank beschreiben mit mehreren Threads Datenbankprogrammierung 18
0 Filtern nach mehreren Kriterien Datenbankprogrammierung 4
S Embedded DB, die aus mehreren JVMs gestartet werden kann? Datenbankprogrammierung 10
H Group By mit mehreren Spalten Datenbankprogrammierung 2
S Verständnisproblem mit mehreren DAOs Datenbankprogrammierung 7
S Verkettung von Spalteninhalten aus mehreren Zeilen Datenbankprogrammierung 10
D aus mehreren sql tabellen matchen und sortieren Datenbankprogrammierung 6
P [Hibernate] Zwischentabelle mit mehreren Feldern Datenbankprogrammierung 7
C Hibernate-Mapping bei mehreren FK´s auf die selbe Tabelle Datenbankprogrammierung 12
J JDBC mit mehreren Threads. Datenbankprogrammierung 8
T [jdbc] einen Eintrag aus mehreren Tabellen löschen (Batch) Datenbankprogrammierung 3
I SaaS Applikation: pro Kunde eine Datenbank / Schema oder eine DB für alle Kunden? Datenbankprogrammierung 76
L MySQL Kunden bestellung abbilden Datenbankprogrammierung 3
S Alle Kunden mit ihren Adressen mit JPQL ausgeben Datenbankprogrammierung 2

Ähnliche Java Themen

Neue Themen


Oben