Andreas: Bestand / Buchung

Hallo zusammen,

habe eine ganz kurze Frage die ich mir nicht selber beantworten kann.

Also angenommen ich brauch einen Bestand.
Dieser Ändert sich anhand der Buchungen (zu- und abbuchung)

Ich habe in meiner Datenbank eine Tabelle Buchungen in der alles enthalten ist.

Macht es sinn jetzt noch eine Tabelle Bestand zu erstellen wo der aktuelle Bestandwert steht, der immer bei einer Buchung mit abgeändert wird.

Oder errechne ich mir den Bestand in meinem Programm anhand der Buchungen.

Was ist sinnvoller?

Danke

  1. Hallo,

    Ich habe in meiner Datenbank eine Tabelle Buchungen in der alles enthalten ist.

    Oha, eine Riesentabelle seit Bestehen der Firma?

    Macht es sinn jetzt noch eine Tabelle Bestand zu erstellen wo der aktuelle Bestandwert steht, der immer bei einer Buchung mit abgeändert wird.

    Auf jeden Fall. Schonmal was von Inventur gehört? Ab dem Inventurdatum interessieren die alten Buchungen für den Bestand nicht mehr.

    Oder errechne ich mir den Bestand in meinem Programm anhand der Buchungen.

    Ja, seit der letzten Inventur.

    Kalle

    1. Relativierung:

      Oder errechne ich mir den Bestand in meinem Programm anhand der Buchungen.

      Ja, seit der letzten Inventur.

      Wie viele Buchungen musst du denn durchhecheln? Wenn es Tausende sind, macht ein mit jeder Buchung aktualisierter Bestand wieder Sinn aus Zeitgründen.

      Damit hast du dann aber ein anderes Problem, wenn nämlich zwei User zeitgleich buchen und jeder geht von dem vorherigen (für beide gleichen) Bestand aus.

      Kalle

      1. noch eine Idee:

        Du könntest mit jeder Buchung den neuen Bestand notieren, also den Buchungssatz um ein Feld erweitern.

        Dann steht der Bestand immer im jüngsten Buchungssatz, also dem mit der höchsten Satz-ID, bezogen auf den Artikel.

        Das Problem mit zeitgleichen Buchungen bleibt.

        Vorausgesetzt, du hast pro Artikel nur einen Bestand. Es könnten ja auch mehrere sein (pro Lager, pro Charge, ...)

        Kalle

        1. noch eine Idee:

          Du könntest mit jeder Buchung den neuen Bestand notieren, also den Buchungssatz um ein Feld erweitern.

          Dann steht der Bestand immer im jüngsten Buchungssatz, also dem mit der höchsten Satz-ID, bezogen auf den Artikel.

          Das Problem mit zeitgleichen Buchungen bleibt.

          Vorausgesetzt, du hast pro Artikel nur einen Bestand. Es könnten ja auch mehrere sein (pro Lager, pro Charge, ...)

          Kalle

          Mir ist gerade etwas eingefallen.

          Man könnte doch beides verbinden, indem man die Buchungen vom aktuellen Tag zusammenzählt und anzeigt. Am nächsten Tag werden die vom aktuellen Tag fest in die Bestandstabelle geschrieben und die neuen Buchungen vom aktuellen Tag wieder zusammengerechnet und mit dem Wert der Bestandstabelle addiert.

          wäre das auch eine Lösung

          1. Mir ist gerade etwas eingefallen.

            Man könnte doch beides verbinden, indem man die Buchungen vom aktuellen Tag zusammenzählt und anzeigt.

            Am nächsten Tag werden die vom aktuellen Tag fest in die Bestandstabelle geschrieben und die neuen Buchungen vom aktuellen Tag wieder zusammengerechnet und mit dem Wert der Bestandstabelle addiert.

            Viel Aufwand mit der Chance, Fehler zu machen.

            Erfahrungsgemäß gibt es irgendwann Probleme, wenn Daten doppelt geführt werden. Also das Original in der Buchungstabelle, die kopierte Summe in der Bestandstabelle.

            Und bei Speicherung der Uhrzeit immer wieder Probleme. Abgesehen davon, dass ein Rechner ungenau "von Hand" gestellt wird (keine eingebaute Funkuhr), ist es mir z.B. nicht gelungen, die Zeit einer Datei auf zwei Servern genau zu vergleichen. Der eine scheint Greenwich Zeit zu nehmen, der andere die gerade gültige deutsche Sommer- oder Winterzeit. Aber sie verraten nicht, was die Grundlage ist. Welche Datei ist die ältere und muss ersetzt werden?

            Die beste Idee scheint mir, die Bestände im Buchungssatz mitzuführen, dann fällt auch die Suche im Fehlerfall leichter, weil vorher - nachher und die genaue (relativ für diesen Server) Zeit der Buchung dokumentiert ist. Und es wird (Programm-) Fehler in der Bestandsführung geben, verlass dich drauf.

            Die Buchung pro Artikel solltest du dann exklusiv machen, also dass kein anderer User für diese Zehntelsekunde einen ändernden Zugriff auf diesen Artikelbestand hat.

            Kalle

            1. Hi,

              Die beste Idee scheint mir, die Bestände im Buchungssatz mitzuführen, dann fällt auch die Suche im Fehlerfall leichter

              Das war für mich ein sehr hilfreiches Argument.
              Auf Grund dessen hab ich das jetzt auch so gemacht, dass ich den Bestand in den Buchungssätzen mitführe.

              Die Buchung pro Artikel solltest du dann exklusiv machen

              Ich habe jetzt dafür gesorgt, dass bei dem Vorgang, die DB Tabelle gesperrt ist und nach Beendigung wieder frei gegeben wird.

              Danke für dein Tips.

              Gruß

        2. Hello,

          noch eine Idee:

          Du könntest mit jeder Buchung den neuen Bestand notieren, also den Buchungssatz um ein Feld erweitern.

          Dann steht der Bestand immer im jüngsten Buchungssatz, also dem mit der höchsten Satz-ID, bezogen auf den Artikel.

          Und genau das geht nicht ohne besondere Maßnahmen bzw. nicht bei allen DBMS.

          Liebe Grüße aus Syburg bei Dortmund

          Tom vom Berg

          --
          Nur selber lernen macht schlau
          http://bergpost.annerschbarrich.de
      2. hi,

        danke für deine Antwort.

        Wie viele Buchungen musst du denn durchhecheln? Wenn es Tausende sind

        Es sind tausende deshalb hatte ich auch ursprünglich vor den Bestand bei jeder Buchung zu aktualisieren. Aber das konntest du natürlich nicht wissen da ich diese Information für mich behalten habe ( sorry :) )

        wenn nämlich zwei User zeitgleich buchen und jeder geht von dem vorherigen (für beide gleichen) Bestand aus.

        Das ist natürlich ein Problem an das ich gar nicht gedacht habe.
        Da muss ich mir irgendwas überlegen, obwohl es eigentlich nicht so wahrscheinlich ist das 2 User zu exakt der selben Zeit buchen. Aber man sollte nie etwas ausschließen.

      3. Hello,

        Oder errechne ich mir den Bestand in meinem Programm anhand der Buchungen.

        Ja, seit der letzten Inventur.

        Wie viele Buchungen musst du denn durchhecheln? Wenn es Tausende sind, macht ein mit jeder Buchung aktualisierter Bestand wieder Sinn aus Zeitgründen.

        Damit hast du dann aber ein anderes Problem, wenn nämlich zwei User zeitgleich buchen und jeder geht von dem vorherigen (für beide gleichen) Bestand aus.

        Das kann nichgt passieren.
        Die Bewegungsdaten sind ohnehin unabhängig von Raceconditions.
        Bei den Kumulationsdaten kann das von Dir beschriebene Szenario aber auch nicht passieren, weil die Datenbank sich darum kümmert.

        Die Rechnung 5-2=3 ist unabhängig von ihrem Zeitpunkt.

        Das Verringern des Bestandes um 2 Einheiten wird also immer das richtige Ergebnis geben, wenn alle Werte innerhalb der erlaubten Grenzen bleiben. Dafür muss man natürlich sorgen.

        Es ist also egal, ob der andere User bereits seine 2 Einheiten abziehen lassen hat, oder es noch tun muss. Die Datenbank rechnet mit ihren Werten aus der Tabelle und diese Rechnung ist atomar gekapselt.

        Liebe Grüße aus Syburg bei Dortmund

        Tom vom Berg

        --
        Nur selber lernen macht schlau
        http://bergpost.annerschbarrich.de
        1. Hello, Tom,

          Es ist also egal, ob der andere User bereits seine 2 Einheiten abziehen lassen hat, oder es noch tun muss. Die Datenbank rechnet mit ihren Werten aus der Tabelle und diese Rechnung ist atomar gekapselt.

          Was bitte ist "atomar gekapselt"?

          Meinst du ein einziges SQL- Statement, also etwa
          UPDATE ... SET bestand = bestand -5

          Aber wie ist es, wenn ich erst den Satz lesen muss? Sagen wir mal, um den Umrechnungsfaktor von Quadratmetern auf Stückzahl (etwa bei Dachziegeln, Laminat usw.) zu erfahren?
          SELECT ....

          Berechnung

          UPDATE ...

          ist das unkritisch? Kann ja sein, dass bei MySQL nur ein einziger User z.Z. auf die Datenbank zugreifen darf. Bei ein paar Zehntel Sekunden Laufzeit kann man das ja nie testen.

          Kalle

          1. Hello,

            Was bitte ist "atomar gekapselt"?

            Prozesse können atomar, zusammengesetzt oder einfach (abstrakt) sein.
            Wenn man zusammengesetzte Prozesse hat, deren Ablauf nicht gestört werden darf, dann kann man sie kapseln, sodass sie nach außen wieder wie ein atomarer (unteilbarer) Prozess aussehen.

            Eine Kapselung erreicht man im einfachsten Fall durch Sperrung des ganzen Systems für fremde Prozesse, deren Ablauf nicht einfach mit deneigenen (zu kapselnden) synchronisierbar ist.

            Meinst du ein einziges SQL- Statement, also etwa
            UPDATE ... SET bestand = bestand -5

            Ja, das wäre dann ein solcher Prozess.

            Aber wie ist es, wenn ich erst den Satz lesen muss? Sagen wir mal, um den Umrechnungsfaktor von Quadratmetern auf Stückzahl (etwa bei Dachziegeln, Laminat usw.) zu erfahren?

            Das ist in dem Moment kritisch, wo zwei Entitäten in den Prozess einbeogen werden, also entweder zwei Tabellen oder zwei Datensätze aus einer oder zwei Tabellen, sowie zwei Prozessarten (Abfrage und Update), die sich nicht binden (kapseln) lassen.

            Manche DBMS können Selects und Subselects binden oder auch Updates mit einem Subselect. Zweiteres würde man hier brauchen.

            Liebe Grüße aus Syburg bei Dortmund

            Tom vom Berg

            --
            Nur selber lernen macht schlau
            http://bergpost.annerschbarrich.de
    2. Macht es sinn jetzt noch eine Tabelle Bestand zu erstellen wo der aktuelle Bestandwert steht, der immer bei einer Buchung mit abgeändert wird.
      Auf jeden Fall. Schonmal was von Inventur gehört? Ab dem Inventurdatum interessieren die alten Buchungen für den Bestand nicht mehr.

      Moment mal. Inventur ist die körperliche Bestandsaufnahme, nicht das Errechnen von Beständen aus vorgenommenen Zu- und Abbuchungen; Letztlich also die Kontrolle, ob das Zahlenwerk der Realität entspricht. Eine Tabelle, welche die Inventursumme enthält, ist überflüssig.

      Sollte sich im Rahmen einer Inventur ein Unterschied zum errechneten Bestand ergeben, ist der errechnete Bestand anzupassen (Zu-/Abbuchung, auch Bestandsveränderung genannt).

      Siechfred

      --
      Chancengleichheit bedeutet nicht, dass jeder einen Apfel pflücken kann, sondern dass der Zwerg eine Leiter bekommt.
  2. Moin,

    ich unterstelle mal, dass die Tabelle nicht Gegenstand der Buchhaltung ist, wir also die speziellen Anforderungen, die ansonsten bei Buchführungsfragen auftauchen könnten, ignorieren können.

    Macht es sinn jetzt noch eine Tabelle Bestand zu erstellen wo der aktuelle Bestandwert steht, der immer bei einer Buchung mit abgeändert wird.
    Oder errechne ich mir den Bestand in meinem Programm anhand der Buchungen.
    Was ist sinnvoller?

    Das kommt drauf an. Wird eh nur der aktuelle Wert abgefragt (Wie groß ist aktuelle Bestand, Ist die Ware lieferbar?, Wieviel Stück kann ich maximal veräußern/verschicken ...), dann wird es sicher sinnvoller sein, eben diese vorrätig zu halten. Wird auch Historie in unterschiedlichen Konstellationen (gestern 14.23, zwischen 01.01.08 und 31.01.08; oder: wieviel blaue/gelbe/große/kleine; oder: wieviel hat x bestellt, wieviel y) abgefragt, sollten die Grunddaten vorgehalten werden.

    Grüße

    Swen