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



## jhjh (2. Nov 2018)

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 (2. Nov 2018)

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 (2. Nov 2018)

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 (2. Nov 2018)

jhjh hat gesagt.:


> Meinst du das mit der seperaten Tabelle in etwa so:


Ja.



jhjh hat gesagt.:


> 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.



jhjh hat gesagt.:


> 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?



jhjh hat gesagt.:


> 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 (2. Nov 2018)

Gibts nur Zahlungseingänge oder auch sowas wie Abonnements oder ähnliches?


----------



## jhjh (8. Nov 2018)

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 (8. Nov 2018)

jhjh hat gesagt.:


> 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...



jhjh hat gesagt.:


> Dann würde die Tabelle in etwa so aussehen:


Ja, so macht man das üblicherweise


----------



## jhjh (9. Nov 2018)

> 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 (9. Nov 2018)

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


----------

