nicht angemeldet
Hallo dedlfix!
Danke für diese ausführliche Antwort!
Die Tabelle ist unnötig, dafür gibt es Vorzeichen, + rein, - raus.
Du meinst also, Ausagben sind dadurch gekennzeichnet, dass es sich beim Betrag um eine negative Zahl handelt. Meine Überlegung war, dass ich mir dann zB. alle Ausgaben einer bestimmten Kategorie in einem bestimmten Zeitraum ausgeben lassen kann. SELECT ... WHERE cashflow = 1. Aber natürlich erreiche ich das auch mit einem SELECT ... WHERE betrag < 0. War das so gemeint von Dir?
Den Kontostand extra zu führen ist nicht notwendig, der ergibt sich aus der Summe der Buchungsbeträge (mit ihren Vorzeichen).
Da stocke ich jetzt etwas mit meinem Verständnis. Wenn ich soetwas wie eine Start-Übersichtsseite mit den Kontoständen all meiner Konten haben möchte, dann ist das mit der "Kontostand"-Spalte eine Abfrage eines einzigen Feldes. Ansonsten wäre ich gezwungen, bei 5 Konten 5 mal die komplette Datenbank durchlaufen zu lassen und mir sämtliche Buchungswerte zusammenzählen zu lassen. Das ist doch über-performancelastig und kompliziert. Oder denkst Du da an einen völlig anderen Weg, den aktuellen Stand ausgeben zu lassen ohne einer eigenen
"Kontostand"-Spalte?
Das hat sogar den Vorteil, dass Fehler auffallen. Dann stimmt nämlich die selbst berechnete Summe nicht mit dem Kontostand überein.
Ich würde ja den Kontostand nicht manuell eintragen. Bei der Speicherung einer neuen Transaktion würde ich einfach den aktuellen Kontostand aufrufen, entsprechend summieren oder subtrahieren und den neuen Wert wieder speichern. Da kann es nicht zu Fehlern kommen. Also noch fehlt mir das verständnis, wieso die "Kontostand"-Spalte nicht gut ist. Ich bitte um weitere Aufklärung und Hilfestellung!
Eventuell möchtest du noch eine Spalte Kontotyp einführen, damit du die Konten zum Beispiel in Zusammenfassungen nach Arten gruppieren kannst.
Dazu sehe ich bei _meinen_ Bedürfnissen keinen Anlass. Meine Konten wären bei 2 verschiedenen Banken jeweils 1 Girokonto und 1 Sparkonto, das Guthaben auf den Quick-Chips der Kundenkarten, dazu ein weiteres Sparkonto bei einer Onlinebank, meine Prepaid Kreditkarte, mein Paypalkonto sowie das Bargeld. Für eine Unterscheidung zwischen den Sparkonten und den Girokonten sehe ich keinen Grund. Beides sind Orte für Geldein- und Geldausgänge. Aber wenn ich Dich richtig verstehe, ging es Dir darum, dass ich sowas brauche, wenn ich zB. das Guthaben aller Sparkonten sehen möchte. Dann wäre evt. auch noch ein "available" Feld interessant. 1 für verfügbares Geld, 0 für nicht verfügbares Geld, wie zB. bei einem gesperrten Sparbuch oder einem Bausparvertrag. Also wenn ich Dich in diesem Punkt richtig verstanden habe, werde ich das mal im Hinterkopf behalten.
3.) Tabelle "Finanzpartner"
4.) Tabelle "Buchungskategorien"
Passt.
Da kommt Freude auf, wenn zumindest _irgendwas_ in meinen Überlegungen fehlerfrei ist! =)
Das hab ich bei mir nicht extra sondern in der Transaktionentabelle drin. Die sieht so aus:
Die von Dir gepostete Tabellenerstellung habe ich bei mir lokal via phpMyAdmin laufen lassen und mir die entstandene Tabelle genauer angesehen. Nach längerer Zeit denke ich, dass ich Dein System zum größten Teil verstanden habe. Aber nur, um das abzuckecken:
Deine Spalte "ID_Account" bezeichnet die ID des Kontos, das bei dieser Transaktion beteiligt ist. Festgelegt durch die IDs in der Tabelle "Accounts" (oder wie immer auch bei Dir bezeichnet.) Richtig?
Und ich nehme an, Deine Spalte "ID_Payee" bezeichnet bei Dir das, was ich als "Finanzpartner" definiert habe, also die gegenseite der Finanztransaktion. Richtig?
Der Idealzustand ist also A. Diese Kennzeichnung gab es damals in MS-Money, und vielleicht ist ihre eigentliche Bedeutung auch eine ganz andere, ich hab es jedenfalls so interpretiert.
Ja, es hat eine andere Bedeutung. Dieses Zeichen wird nur fälschlicherweise für ein A gehalten. In Wirklichkeit ist der obere Teil des Zeichens eine Pyramide und zeigt die Verbindung zu Freimaurern und Illuminaten. In Verbindung mit den beiden "Füßen" am unteren Rand der Pyramide entsteht das skizzierte Bild der angeblichen Mondlandekapsel "Eagle". Aber wie wir alle wissen, war die Mondlandung eine Lüge.
Doch zurück zu Deiner Antwort: Interessant finde ich Deine Idee mit der "ReferenceID" Spalte, die im Falle einer Splitbuchung den Bezug zur "Gesamtrechnung" darstellt und im Falle einer internen Umbuchung die Buchungs-ID der Gegenseite zeigt.
Was ich am wenigsten verstehe, ist die Spalte "Sort":
Sort bekommt bei Bedarf eine Nummer, um Buchungen (=Transaktionen) eines Tages definiert anordnen zu können. Das ist nur Optik und kann auch wegbleiben.
Dazu kann ich mir absolut nichts vorstellen. Meinst Du, dass da temporär etwas in dieser Spalte gespeichert wird und nach einer Berechnung/Ausgabe wieder gelöscht wird? Kannst Du das praktisch irgendwie erläutern?
Also was ich mir auf jeden Fall schon mal mitnehme von Deiner Antwort:
Ich werde komplett auf die Tabelle "Cashflow" verzichten und Einnahmen/Ausgaben anhand der positiven/negativen Zahl im "Betrag" Feld identifizieren.
Ich werde komplett auf die Tabelle "Interne Umbuchungen" verzichten und das so wie Du lösen. Dazu habe ich mir auch schon Gedanken gemacht. Ich arbeite ja mit PDO als Verbindung zwischen php und MySQL. Mit $id = $db -> lastInsertId() bekomme ich nach dem Speichern der ersten Buchung die ID, verwende diese dann als Wert für die ReferenceID bei der Speicherung der 2. Buchung, bekomme hier wiederum mit $id = $db -> lastInsertId() zur ID und mit einem SET ... WHERE ID = ... wird dieser Wert dann noch bei der ersten Buchung als ReferenceID nachgetragen. Das gefällt mir!
Wovon Du mich nicht überzeugt hast, ist Dein Zusammenschluss von Einzelbuchungen und Splitbuchungen. Für mich ist das einfach nicht das Selbe. Wenn ich beim Aldi 1 Banane, 1 Joghurt und 1 Wurst kaufe, dann bezahle ich ja an der Kasse nicht 3 Mal hintereinander jedes einzelne Produkt extra. Es gibt _einen_ Bezahlvorgang. Das, was ich als Transaktion bezeichne. Diese Transaktion hat einen Empfänger, ein Datum und einen Gesamtbetrag. Um welche Produkte es sich dabei genau gehandelt hat und was die Preise dieser Einzelprodukte waren, ist wieder eine andere Sache. Dafür die Buchungstabelle, die die Splitrechnungen aufzeigt. Hier wiederum ist für mich der Empfänger und das Datum uninteressant, da durch die ReferenceID der Bezug zur Gesamtrechnung ja gegeben ist. Ich kann mich einfach nicht damit anfreunden, das in eine einzige Tabelle zu stecken. Nicht, weil es mir technisch zu kompliziert wäre oder ich Dein Konzept nicht verstehe, sondern weil ich einfach 2 verschiedene Dinge darin sehe und mich dagegen sträube, die in einen Topf zu werfen. Findest Du das wirklich _so_ schlimm/falsch?
Recht hast Du natürlich damit, dass die Gesamtvermögensberechnungen auf Grund der Transaktionen, also der Hauptrechnungen durchgeführt werden.
Das wäre mir viel zu zeitaufwendig ohne weiteren Nutzen. Kategorie Lebensmittel für den gesamten Einkauf und gut ist. Eventuell kann man das splitten, wenn was besonderes dabei war, dann aber in „besonderes Ding“ und „Rest“.
Nun ja, in diesem Punkt bin ich wohl ein kleiner Erbsenzähler. :)
Beachte auch, als Spaltentyp für die Beträge DECIMAL und nicht FLOAT zu verwenden, sonst gibt es den bekannten und befürchteten Ärger mit ungenauer Abbildbarkeit von Nachkommastellen im Dualsystem (à la 1 - 0.1 = 0.89999999).
Ich weiß jetzt nicht genau, was Du damit meinst, aber ich habe hier beim Mitlesen im Forum schon ein paar Mal mitbekommen, dass es bei Verwendung von FLOAT Probleme gibt. Wenn ich mich richtig erinnere, auch ber der Berechnung von Mittelwerten oder Ähnlichem. Danke für den Hinweis, dann verwende ich DECIMAL! (Nur so nebenbei: Wenn es mit FLOAT so viele Fälle gibt, die Probleme machen, wann verwendet man es dann denn auf jeden Fall _statt_ dem DECIMAL? Irgend eine Daseinsberechtigung muss es ja haben?!)
Was jetzt also als Frage offen bleibt ist die Sache mit dem Weglassen der Spalte für den aktuellen Kontostand und die Sache mit dem Sort.
Mit lieben Grüßen
Melvin Cowznofski
What – me worry?