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

Diskutiere Zahlungseingänge von mehreren Kunden wie am besten abbilden in der Datenbank ? im Datenbankprogrammierung Forum; Hallo, Über eine SQLite Datenbank (wird über eine Android App verwendet) verwalte ich immoment gut 100 Kunden. Die Datenbank besitzt bisher...

  1. jhjh
    jhjh Neues 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 =)
     
  2. Vielleicht hilft dir diese Seite hier weiter (Klick!)
  3. mihe7
    mihe7 Bekanntes Mitglied
    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.
     
  4. jhjh
    jhjh Neues Mitglied
    Hallo, danke erstmal für deine Antwort =)
    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 ?

    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)
     
  5. mihe7
    mihe7 Bekanntes Mitglied
    Ja.

    Im Allgemeinen nicht aber im konkreten Fall könnte dies durchaus sein.

    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?

    Wenn das alles ist, brauchst Du Dir keine großen Gedanken zu machen.
     
  6. mrBrown
    mrBrown Super-Moderator Mitarbeiter
    Gibts nur Zahlungseingänge oder auch sowas wie Abonnements oder ähnliches?
     
    Zuletzt bearbeitet: 2. Nov. 2018
  7. jhjh
    jhjh Neues 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.
    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)
    ...

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

    Ja, so macht man das üblicherweise :)
     
  9. jhjh
    jhjh Neues Mitglied
    Ah ok, verstehe!

    Ich weiß jetzt erstmal Bescheid! Falls es noch zu Problemen kommen sollte, würde ich mich ggf nochmal melden.
    Danke nochmal! =)
     
  10. Thallius
    Thallius Bekanntes Mitglied
    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
     
  11. Hinweis: Du möchtest Java lernen? Vielleicht hilft dir dieses Training hier weiter. Sichere dir hier den Zugriff auf umfangreiches Java-Know How und starte richtig durch!
Die Seite wird geladen...

Zahlungseingänge von mehreren Kunden wie am besten abbilden in der Datenbank ? - Ähnliche Themen

Geburtsdaten von Mehreren Personen speichern und Alter ausgeben
Geburtsdaten von Mehreren Personen speichern und Alter ausgeben im Forum Java Basics - Anfänger-Themen
Methode im Interface mit mehreren Parametern
Methode im Interface mit mehreren Parametern im Forum Java Basics - Anfänger-Themen
Aus MEHREREN Excel Tabellen bestimmte Zelle addieren
Aus MEHREREN Excel Tabellen bestimmte Zelle addieren im Forum Allgemeine Java-Themen
Taschenrechner mit mehreren Rechnungen
Taschenrechner mit mehreren Rechnungen im Forum AWT, Swing, JavaFX & SWT
Objekt-Suche mit mehreren optionalen Parametern
Objekt-Suche mit mehreren optionalen Parametern im Forum Allgemeine Java-Themen
Thema: Zahlungseingänge von mehreren Kunden wie am besten abbilden in der Datenbank ?